I absolutely agree with John, and I think, we should push this through evolution process.
That old voting wasn't public, or "official". I insist that we decide this via a formal review. Even if it means that the proposal will be explicitly rejected. - Anton 2016-05-02 22:07 GMT+03:00 John McCall <rjmcc...@apple.com>: > > On May 2, 2016, at 11:47 AM, Chris Lattner <clatt...@apple.com> wrote: > > 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. > > 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution