[swift-evolution] [Idea] "guard not let" optional binding

[John Morgan]

I've occasionally hit this problem but I don’t think this warrants a
language addition, as it can be overcome in other ways. I would move the
expensive calculation into its own private method and rewrite your example
like this:

return cachedValue ?? calculatedValue()

In my opinion that would fit better with the single responsibility
principle and make unit testing easier.

John

> -1 as there IMO some confusion between all these `not` and `else` and the
> meaning of the expression at all is not obvious for me: "check that not
> allowed to assign _someExpensiveResult to some instance cachedValue,
> otherwise return something"
>
> This really looks nice, clean and obvious :
>
> guard cachedValue == nil else {
> // here you need just to fast return unwrapped value of cachedValue
> // so, IMO unwrapping it in this block is OK
> return cachedValue!
> }
> // here you want to have cachedValue == nil, so you'll need to unwrap
> it(after assignment) in any case.
>
> What I can see as improvement in this direction, something like this:
> guard cachedValue == nil else let cachedValue! {
> // here you can use unwrapped cachedValue
> return cachedValue
> }
>
>
> Hmm... Btw, what about improving in optional binding: It is common to
> shadow optional value name with unwrapped value with same name:
>
> if let value = value {...} // too much noise
>
> What about introduce such syntax:
>
> if let value! {
> // unwrapped value here
> }
>
> Seems like clear and obvious about what does this mean. Opinions? (before
I
> drop this to separate thread)
>
>
> On 14.05.2016 8:52, Karl via swift-evolution 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
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160516/e0b8cd6a/attachment.html>