[swift-evolution] [Idea] Remove optional pattern binding

[John McCall]

> On May 2, 2016, at 11:47 AM, Chris Lattner <clattner at apple.com> wrote:
> On May 2, 2016, at 11:12 AM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>>>> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>>> Pattern binding for optionals will look like:
>>>>> 
>>>>> if let x? = y { ... }
>>>> 
>>>> I suggested precisely this in February. The core team shot it down:
>>>> 
>>>>> We tried this* and got a lot of negative feedback. Optionals are unwrapped too often for people to be comfortable writing "if let name? = optionalCondition".
>>>> 
>>>> 
>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008964.html
>>>> 
>>>> Having said that, this still seems like a good idea to me, but they're the ones with implementation experience; all I have is an elegant idea.
>>> 
>>> Yeah, as nice as it sounds, it didn’t work out in practice. I’ll add it to the frequently-suggested list.
>> 
>> Yeah.  My take on it is that 'if let' was probably a mistake, but once we made it, it was really hard to back out.
> 
> I understand that you (and probably a ton of other people on this list) feel that way, but I disagree pretty strongly.  I think we have the right design here.
> 
> Context: As was mentioned up-thread, in the Swift 2 development cycle, we significantly extended pattern matching (this is when we added ‘if case’, etc).  One of the things we implemented - but then backed out - was exactly the proposal above. We did this because we found it to be the *wrong* thing to do.
> 
> The reason is simple: most developers don’t grok pattern matching.  Particularly for people new to swift, “if let” is taught as a magic for dealing with optionals (which it is). This is a very useful mechanic when working in Swift, and this way of thinking is fine.  Optionals are very prominent, and having special sugar for dealing with them is important, even as people grow to become swift experts in time.
> 
> Going with the proposal would definitely simplify the language ('if case’ could probably go away), but would force everyone, all the time, to think about pattern matching.  This would be a barrier to entry that many programmers should never have to face.  The fact that many people don’t think about things in terms of pattern matching is the root cause for the comments about “it seems weird that the question mark is on the LHS of the assignment”.
> 
> Finally, some may argue that making pattern matching more prominent would help teach pattern matching and get more people to use it.  That may be true, but our goal here is to build a pragmatic language that helps people get things done, not push to one specific language feature.  I personally love pattern matching (and was the one who drove and implemented the Swift 2 pattern matching enhancements), but it is an esoteric and special case feature.  It makes sense for it to be “buried” under “if case”: those who are unfamiliar with the syntax have something they can google for.

I understand what you're saying here, but I don't think your conclusions follow.  You wouldn't teach "if let x? = whatever" as an aspect of a generic pattern-matching feature just because "x?" happens to be a pattern.  You would still introduce it as magic for dealing with optionals, and the syntax would nicely reinforce a general impression that "? is how I deal with optionals".  Instead, it feels more magical because nothing about the syntax suggests optionals; it's just something you have to know.

Meanwhile the "if let" syntax has proven to compose poorly, and in particular it makes compound conditions unnecessarily limited/awkward because you can't bind a non-optional value and then test something about it without doing something like "if let x = Optional(whatever) where x.isBeautiful".

Anyway, like I said, I don't think it's something we can change.

John.