> On May 2, 2016, at 12:13 PM, Антон Жилин <antonyzhi...@gmail.com> wrote: > 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.
You are welcome to submit an evolution proposal. If we think it's in good shape, we'll put it through review. However, it not a goal of the evolution process to retroactively approve the entire language design. Just because a decision was made before the public evolution process started doesn't mean the decision is unofficial or illegitimate. John. > > - Anton > > 2016-05-02 22:07 GMT+03:00 John McCall <rjmcc...@apple.com > <mailto:rjmcc...@apple.com>>: > > On May 2, 2016, at 11:47 AM, Chris Lattner <clatt...@apple.com > > <mailto:clatt...@apple.com>> wrote: > > On May 2, 2016, at 11:12 AM, John McCall via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> > >>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution > >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>>> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution > >>>> <swift-evolution@swift.org <mailto: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 > >>>> > >>>> <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
