Why doesn't 'guard let ...' allow non-optionals?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Why doesn't 'guard let ...' allow non-optionals?

Jens Alfke
It seems inconsistent that I can use a ‘guard’ statement to bind an optional value, but not to bind anything else. For example, if foo.color is an optional I can use
guard let color = foo.color else { return }  // works
but if foo.count is an integer I can’t use
guard let count = foo.count where foo.count > 0 else { return }  // syntax error
This would actually work as long as foo.count were an optional integer, which seems like a weird requirement in this case.

I’m finding this is getting in the way of my using ‘guard let...’ as a uniform way of expressing preconditions in methods, because of course not all preconditions involve optionals.

I know I can do
let count = foo.count
guard foo.count > 0 else { return }
but it would feel more consistent (and compact!) to be able to use ‘guard let’ in all cases.

—Jens

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/91453610-7ED2-4479-9814-B26524692A9B%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't 'guard let ...' allow non-optionals?

Adam Sharp
I agree, it seems like a frustrating limitation. However I think your example can work if you just throw a "case" in front of your "let":

guard case let count = foo.count where foo.count > 0 else { return }

–Adam

On 15 Jul 2015, at 8:18 am, Jens Alfke <[hidden email]> wrote:

It seems inconsistent that I can use a ‘guard’ statement to bind an optional value, but not to bind anything else. For example, if foo.color is an optional I can use
guard let color = foo.color else { return }  // works
but if foo.count is an integer I can’t use
guard let count = foo.count where foo.count > 0 else { return }  // syntax error
This would actually work as long as foo.count were an optional integer, which seems like a weird requirement in this case.

I’m finding this is getting in the way of my using ‘guard let...’ as a uniform way of expressing preconditions in methods, because of course not all preconditions involve optionals.

I know I can do
let count = foo.count
guard foo.count > 0 else { return }
but it would feel more consistent (and compact!) to be able to use ‘guard let’ in all cases.

—Jens

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/91453610-7ED2-4479-9814-B26524692A9B%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/D990DC4F-49F4-47EF-8148-37706BFF7BE9%40me.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't 'guard let ...' allow non-optionals?

Marco S Hyman

> On Jul 14, 2015, at 4:10 PM, Adam Sharp <[hidden email]> wrote:
>
> I agree, it seems like a frustrating limitation. However I think your example can work if you just throw a "case" in front of your "let":
>
> guard case let count = foo.count where foo.count > 0 else { return }

That brings up another “case” that confuses me.

let bar: Int? = 42

if let foo = bar {
    print(foo)
}

if case let foo? = bar {
    print(foo)
}

Both print “42\n”.  I haven’t yet wrapped my head around why the case version
requires foo? instead of foo unless I want foo to be optional ???

Marc

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/1CBDA983-8D17-4A68-99D5-D7E37E3BD69A%40snafu.org.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't 'guard let ...' allow non-optionals?

Jens Alfke
In reply to this post by Adam Sharp

On Jul 14, 2015, at 4:10 PM, Adam Sharp <[hidden email]> wrote:

I agree, it seems like a frustrating limitation. However I think your example can work if you just throw a "case" in front of your "let":

guard case let count = foo.count where foo.count > 0 else { return }

Ah, thanks! I’m still coming to grips with the way 'case' has been detached from its longtime home in ‘switch’ statements and can now be sprinkled into other contexts like this. O_o

—Jens

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/D899EE03-9083-4F7B-A105-3865BEC76D79%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't 'guard let ...' allow non-optionals?

Adam Sharp
On 15 Jul 2015, at 11:21 am, Jens Alfke <[hidden email]> wrote:

On Jul 14, 2015, at 4:10 PM, Adam Sharp <[hidden email]> wrote:

I agree, it seems like a frustrating limitation. However I think your example can work if you just throw a "case" in front of your "let":

guard case let count = foo.count where foo.count > 0 else { return }

Ah, thanks! I’m still coming to grips with the way 'case' has been detached from its longtime home in ‘switch’ statements and can now be sprinkled into other contexts like this. O_o

Yeah, to be honest it feels like the number of keywords and the rules for their use is getting close to becoming unwieldy. In this case (heh) it almost begins to feel a little arbitrary, or at least unintuitive.

–Adam

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/8C6D4D72-EA32-4143-8F0C-F34D23028D7D%40me.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't 'guard let ...' allow non-optionals?

Swift Language mailing list
In reply to this post by Jens Alfke

> On 14 Jul 2015, at 23:18, Jens Alfke <[hidden email]> wrote:
>
> It seems inconsistent that I can use a ‘guard’ statement to bind an optional value, but not to bind anything else. For example, if foo.color is an optional I can use
> guard let color = foo.color else { return }  // works
> but if foo.count is an integer I can’t use
> guard let count = foo.count where foo.count > 0 else { return }  // syntax error

Why?  The former case unwraps an optional, the latter case does nothing that guard foo.count > 0 doesn't do.

> This would actually work as long as foo.count were an optional integer, which seems like a weird requirement in this case.
>
> I’m finding this is getting in the way of my using ‘guard let...’ as a uniform way of expressing preconditions in methods,
> because of course not all preconditions involve optionals.
>
> I know I can do
> let count = foo.count
> guard foo.count > 0 else { return }
> but it would feel more consistent (and compact!) to be able to use ‘guard let’ in all cases.

IF you allow

guard let something = somethingThatIsNotAnOptional where blah

you are also into

if let something = somethingThatIsNotAnOptional where blah

and

while let something = somethingThatIsNotAnOptional where blah

which kind of obfuscates the meaning a bit by putting the only thing that matters (the conditional) at the end.

if blah
{
    let something = somethingThatIsNotAnOptional
    ...
}

is a bit easier to understand IMO

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/ED750886-5AF4-41BD-89E0-2496AB30F97A%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't 'guard let ...' allow non-optionals?

Leonardo Faoro
In reply to this post by Jens Alfke
Code should first of all be readable, allowing guard let for everything would confuse other programmers reading the code which expect an Optional out of this syntax.

On Wednesday, July 15, 2015 at 12:18:14 AM UTC+2, Jens Alfke wrote:
It seems inconsistent that I can use a ‘guard’ statement to bind an optional value, but not to bind anything else. For example, if foo.color is an optional I can use
guard let color = foo.color else { return }  // works
but if foo.count is an integer I can’t use
guard let count = foo.count where foo.count > 0 else { return }  // syntax error
This would actually work as long as foo.count were an optional integer, which seems like a weird requirement in this case.

I’m finding this is getting in the way of my using ‘guard let...’ as a uniform way of expressing preconditions in methods, because of course not all preconditions involve optionals.

I know I can do
let count = foo.count
guard foo.count > 0 else { return }
but it would feel more consistent (and compact!) to be able to use ‘guard let’ in all cases.

—Jens

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/4132440a-3799-4b8a-945f-a094d97ecf66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't 'guard let ...' allow non-optionals?

Jens Alfke

On Jul 16, 2015, at 5:10 AM, Leonardo Faoro <[hidden email]> wrote:

Code should first of all be readable, allowing guard let for everything would confuse other programmers reading the code which expect an Optional out of this syntax.

I see the purpose of ‘guard’ as being to enforce a precondition. When you see a ‘guard’ statement you know that, unless the following condition is met, the flow of control cannot continue. That’s very valuable for readability and maintainability.

But you’re correct that the syntax for a non-optional binding in a guard doesn’t start with ‘guard let’. I’m happy with that; I just want the ability to do it.

—Jens

--
You received this message because you are subscribed to the Google Groups "Swift Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/swift-language/8ABC007C-4355-462F-AA8E-8882E5FF3A4E%40mooseyard.com.
For more options, visit https://groups.google.com/d/optout.