[swift-evolution] [Pitch] Introducing `Unwrappable` protocol

[Derrick Ho]

I disagree that the following is better

guard unwrap foo else { ... } // simpler?

It feels like you are re-using foo which previously was an optional but now
is something else. If a variable is a cup, then you'd be reusing a cup that
previously had a different drink in it.

guard let foo = foo else { ... } // current

The current version is preferred since it looks like you are using a new
"cup" to store your non-optional. I like that it is explicit.
On Tue, Mar 7, 2017 at 9:27 PM Greg Parker via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Mar 7, 2017, at 3:49 PM, Jaden Geller via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> It’s worth mentioning that the normal let binding can be used for pattern
> matching:
>   let (a, b, c) = foo()
>
> This nicely parallels the existing case syntax:
>   if case let .blah(a, b, c) = bar() { … }
> It would feel inconsistent if the order switched when in a conditional
> binding.
>
> I would prefer that `case` was removed to best mirror the normal syntax,
> requiring `?` or `.some` to be used for optionals
>   if let .blah(a, b, c) = bar() { … }
>   if let unwrapped? = wrapped { … }
>   if let .some(unwrapped) = wrapped { … }
> but I realize this is source-breaking, so I’m happy with the existing
> syntax.
>
>
> We tried `if let unwrapped? = wrapped` some time ago. It was unbelievably
> unpopular. We changed it back.
>
>
> --
> Greg Parker     gparker at apple.com     Runtime Wrangler
>
>
> _______________________________________________
> 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/20170308/809894f2/attachment.html>