On May 2, 2016, at 11:12 AM, John McCall via swift-evolution
<swift-evolution@swift.org> wrote:
>
>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution
>>> <swift-evolution@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.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
