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