<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Question coming of a pure curiosity, although somewhat related: isn’t the fact that the Optional is an enum just an implementation detail? I thought this was the case.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">From this perspective `if let value = optional` is and will stay an optional-only syntax regardless of the implementation. `if case let .some(value) = optional` is just a special case of applying the pattern matching, which is related to the Optional type only via the current implementation.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Cheers,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Krzysztof</div> <div id="bloop_sign_1462215647992748032" class="bloop_sign"></div> <br><p class="airmail_on">On 2 May 2016 at 20:47:49, Chris Lattner via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>On May 2, 2016, at 11:12 AM, John McCall via swift-evolution <swift-evolution@swift.org> wrote:<br>> <br>>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:<br>>>> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:<br>>>> <br>>>>> Pattern binding for optionals will look like:<br>>>>> <br>>>>> if let x? = y { ... }<br>>>> <br>>>> I suggested precisely this in February. The core team shot it down:<br>>>> <br>>>>> 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".<br>>>> <br>>>> <br>>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008964.html<br>>>> <br>>>> 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.<br>>> <br>>> Yeah, as nice as it sounds, it didn’t work out in practice. I’ll add it to the frequently-suggested list.<br>> <br>> 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.<br><br>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.<br><br>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.<br><br>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.<br><br>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”.<br><br>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.<br><br>-Chris<br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></body></html>