[swift-evolution] [Idea] Remove optional pattern binding

[Антон Жилин]

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 <rjmccall at apple.com>:

> > On May 2, 2016, at 11:47 AM, Chris Lattner <clattner at apple.com> wrote:
> > 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.
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160502/6be92051/attachment.html>