[swift-evolution] [Idea] Remove optional pattern binding
Michael Peternell
michael.peternell at gmx.at
Mon May 2 14:55:56 CDT 2016
I totally agree with you. I think there are many things that are really well-designed in Swift 2 currently, and most things should stay the way they are. I felt that it is really easy to learn (compared to other languages like, e.g. Perl or Haskell at least) and that the code usually works as expected, without great surprises. (But I cannot write a proposal, listing all the stuff from Swift 2.2 that I want to remain unchanged, can I? ;-)
I think using a programming language shouldn't be an intelligence test as there are already enough ways that intelligent people can prove their abilities. Anyways, I like Haskell much, although it is much more complicated, because I think that it is also very powerful. But writing `if let x? = y` instead of `if let x = y` doesn't seem to make Swift any more powerful than it already is. And since there is already an `if case` if you really want to do pattern matching (I didn't know that), I think there is even less reason to change the `if let` construct. It also optimizes my mental code parsing speed if I can hard-wire the fact that `if let` and `guard let` relates to optional binding.
just my 2 cents
-Michael
> Am 02.05.2016 um 20:47 schrieb Chris Lattner via swift-evolution <swift-evolution at swift.org>:
>
> 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.
>
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list