You could do that with everything and never use the guard statement at all if
you wanted.
But it's actually pretty useful. There have been times where I’ve been heavily
editing code and forgotten to leave the scope after a guard condition failed.
Just recently I was editing some async functions with a callback with a
throwable argument, I called the callback with the error but forgot to return
afterwards; guard caught it for me.
Lets say I had your code, but was editing it to make it asynchronous:
if let value = cachedValue { return value }
cachedValue = // … expensive calculation
return cachedValue!
could become (if I was tired, in the middle of some big code changes):
if let value = cachedValue { callback(value) } // Oops, forgot to return,
redundant re-calculation (and unexpected second callback) follows
cachedValue = // … expensive calculation
callback(cachedValue!)
guard wouldn’t let that happen. I use it every time I intend to exit scope
early; it’s a better semantic model of my intention, so the compiler will
notice on the off-chance I do mess up.
> On 14 May 2016, at 07:56, Patrick Smith <[email protected]> wrote:
>
> I’d probably write that as:
>
> if let value = cachedValue { return value }
>
> cachedValue = // … expensive calculation
>
>
>> On 14 May 2016, at 3:52 PM, Karl via swift-evolution
>> <[email protected]> wrote:
>>
>> If we want to check that an optional has a value and bail if it doesn't, we
>> have the helpful pattern:
>>
>> guard let x = x else { throw SomeError }
>>
>> However, it is also fairly common that you want to check that an optional
>> *is* nil, and still bail if it isn’t (maybe using the value that you now
>> know exists), e.g:
>>
>> guard cachedValue == nil else { return cachedValue! }
>> cachedValue = //… expensive calculation
>>
>> It seems a little bit “unfair” that we have this lovely clean `let` syntax
>> when checking for Optional.Some, but we to have to do this ugly manual check
>> against nil and explicit unwrap when checking for Optional.None. There is
>> literally no other way to satisfy the guard statement; our optional bindings
>> only go one-way can’t be evaluated.
>>
>> What about if we introduced a “not” modifier to optional bindings?
>>
>> guard not let cachedValue = _someExpensiveResult else { return cachedValue
>> }
>>
>> This obviously wouldn’t make sense for “if let…” switching, as the variables
>> get bound in the ‘else’ block and the code wouldn’t be very readable. For
>> the special case of a guard statement, though, which only has an ‘else’
>> block, it does make some sense.
>>
>> If we had something like this, certainly in my code, I’d be able to
>> eliminate almost all (maybe even all) remaining force-unwraps of optionals;
>> that’s great! It’d be amazing if the language was expressive enough that you
>> could go without ever having to force-unwrap an optional. And it just makes
>> sense.
>>
>> Thoughts?
>>
>> Karl
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
