But if "case" is removed, doesn't that introduce an ambiguity? In an
admittedly contrived pathological case, you could have an "=" operator
which returns a Bool; then "if .someCase = myvar" would be ambiguous.
Jacob
···
On Sun, May 1, 2016 at 1:12 AM, Антон Жилин <swift-evolution@swift.org> wrote:
Generally, pattern binding in `if` looks like this:
if case *pattern* = *expression* { ... }
Pattern binding for optionals is currently usable as both of:
if case let .some(x) = y { ... }
if case let x? = y { ... }
Now, there is also an older optional-specific hack:
if let x = y { ... }
In terms of pattern binding, it should always be true, and it's illogical
inside `if`.
I suggest:
1) Remove optional pattern binding
2) Remove `case` in `if` pattern binding
Really, `case` should be an attribute of `switch`, not `if`.
Pattern binding for optionals will look like:
if let x? = y { ... }
It will become more explicit and consistent with the rest of the language.
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".
Would take a little getting used to, but I think I’d be fine with it, as the way things are now is inconsistent with regular assignments (which remain optional).
My only concern is why the question mark on the left hand side? I don’t really have any concrete reason against it, but it just feels kind of odd to me, I’m just hoping for some reasoning why some of the alternatives aren’t better fits like:
if let x = y? { … } // More like optional chaining, which is familiar as an “if non-nil proceed” behaviour
if let x ?= y { … } // More obviously a special type of assignment that could fail if y is nil
Again, I’m in favour, I’m just curious why the mentioned format, were others considered previously, or is just because that’s how the case-keyword form does it? (I don’t use it as I’ve never liked that form, and it doesn’t seem that well known anyway).
···
On 1 May 2016, at 09:12, Антон Жилин <antonyzhilin@gmail.com> wrote:
Yeah, as nice as it sounds, it didn’t work out in practice. I’ll add it to the frequently-suggested list.
(I’m not actually core team, but I was around for the experiment.)
Jordan
···
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".
On 1 May 2016, at 09:12, Антон Жилин <antonyzhilin@gmail.com> wrote:
Pattern binding for optionals will look like:
if let x? = y { … }
Would take a little getting used to, but I think I’d be fine with it, as
the way things are now is inconsistent with regular assignments (which
remain optional).
My only concern is why the question mark on the left hand side? I don’t
really have any concrete reason against it, but it just feels kind of odd
to me, I’m just hoping for some reasoning why some of the alternatives
aren’t better fits like:
if let x = y? { … } // More like optional chaining, which is familiar as
an “if non-nil proceed” behaviour
if let x ?= y { … } // More obviously a special type of assignment that
could fail if y is nil
Again, I’m in favour, I’m just curious why the mentioned format, were
others considered previously, or is just because that’s how the
case-keyword form does it? (I don’t use it as I’ve never liked that form,
and it doesn’t seem that well known anyway).
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.
John.
···
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".
On 1 May 2016, at 09:12, Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@gmail.com>> wrote:
Pattern binding for optionals will look like:
if let x? = y { … }
Would take a little getting used to, but I think I’d be fine with it, as the way things are now is inconsistent with regular assignments (which remain optional).
My only concern is why the question mark on the left hand side? I don’t really have any concrete reason against it, but it just feels kind of odd to me, I’m just hoping for some reasoning why some of the alternatives aren’t better fits like:
if let x = y? { … } // More like optional chaining, which is familiar as an “if non-nil proceed” behaviour
if let x ?= y { … } // More obviously a special type of assignment that could fail if y is nil
Again, I’m in favour, I’m just curious why the mentioned format, were others considered previously, or is just because that’s how the case-keyword form does it? (I don’t use it as I’ve never liked that form, and it doesn’t seem that well known anyway).
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.
-Chris
···
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".
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.
···
On May 2, 2016, at 11:47 AM, Chris Lattner <clattner@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".
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.
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.
My issue is that while one needs to have a special behavior in this case to combine conditional logic and variable assignment, the current shorthand is nonintuitive/inconsistent. The current syntax makes it look like you are saying “let y=x”, and that now assignment has different behaviors if you are inside or outside a conditional. Why does assignment sometime cast off optionality?
let x:Optional = 1 // x: Int? = 1
if let y = x {
print(y.dynamicType) // Int
}
let y = x
print(y.dynamicType) // Optional<Int>
If there were a syntax like “if let y = some x”, then it would be clear that there is more to this statement than an assignment, it would make it clearer why you can’t cast off optionality on other assignments, as well as possibly being a segue to learning about full pattern matching.
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.
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.
Cheers,
Krzysztof
···
On 2 May 2016 at 20:47:49, Chris Lattner via swift-evolution (swift-evolution@swift.org) 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".
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 totally agree with you. I think there are many things that are really well-designed in Swift 2 currently, and most things should stay the way they are. I felt that it is really easy to learn (compared to other languages like, e.g. Perl or Haskell at least) and that the code usually works as expected, without great surprises. (But I cannot write a proposal, listing all the stuff from Swift 2.2 that I want to remain unchanged, can I? ;-)
I think using a programming language shouldn't be an intelligence test as there are already enough ways that intelligent people can prove their abilities. Anyways, I like Haskell much, although it is much more complicated, because I think that it is also very powerful. But writing `if let x? = y` instead of `if let x = y` doesn't seem to make Swift any more powerful than it already is. And since there is already an `if case` if you really want to do pattern matching (I didn't know that), I think there is even less reason to change the `if let` construct. It also optimizes my mental code parsing speed if I can hard-wire the fact that `if let` and `guard let` relates to optional binding.
just my 2 cents
-Michael
···
Am 02.05.2016 um 20:47 schrieb Chris Lattner via swift-evolution <swift-evolution@swift.org>:
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".
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.
This to me is the most bizarre thing about the if-let construct. Elsewhere in the language ? indicates conditional unwrapping.
This would make more sense to me:
if let y = x? {
print(y.dynamicType) // Int
}
My issue with the proposed pattern matching syntax is that it looks like assignment, which I think confuses people. This is one thing that the current case syntax helps to mitigate.
if let y? = x {
print(y.dynamicType) // Int
}
Not that I’m suggesting this exactly, but the for-loop syntax works well. Maybe there is a more clear pattern matching syntax?
if let y? in x {
print(y.dynamicType) // Int
}
···
On May 2, 2016, at 1:08 PM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:
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.
My issue is that while one needs to have a special behavior in this case to combine conditional logic and variable assignment, the current shorthand is nonintuitive/inconsistent. The current syntax makes it look like you are saying “let y=x”, and that now assignment has different behaviors if you are inside or outside a conditional. Why does assignment sometime cast off optionality?
let x:Optional = 1 // x: Int? = 1
if let y = x {
print(y.dynamicType) // Int
}
let y = x
print(y.dynamicType) // Optional<Int>
If there were a syntax like “if let y = some x”, then it would be clear that there is more to this statement than an assignment, it would make it clearer why you can’t cast off optionality on other assignments, as well as possibly being a segue to learning about full pattern matching.
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@apple.com>:
> On May 2, 2016, at 11:47 AM, Chris Lattner <clattner@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".
>>>>
>>>>
>>>> [swift-evolution] Obsoleting `if let`
>>>>
>>>> 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.
When the core team implemented the `if let x? = y` experiment and later backtracked, were you enthusiastic about it? The way Jordan puts it "Yeah, as nice as it sounds, it didn’t work out in practice.” sounds very definite, as if it was an obvious and unanimous decision to backtrack.
I think I’m more of Chris’ opinion, but I’d like to understand your point of view better.
David.
···
On 02 May 2016, at 21:07, John McCall via swift-evolution <swift-evolution@swift.org> wrote:
On May 2, 2016, at 11:47 AM, Chris Lattner <clattner@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".
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.
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.
···
On May 2, 2016, at 12:13 PM, Антон Жилин <antonyzhilin@gmail.com> wrote:
- Anton
2016-05-02 22:07 GMT+03:00 John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>>:
> On May 2, 2016, at 11:47 AM, Chris Lattner <clattner@apple.com <mailto:clattner@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".
>>>>
>>>>
>>>> [swift-evolution] Obsoleting `if let`
>>>>
>>>> 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.
Unless there is some “new information”, I don’t see any reason to waste the communities time on this.
-Chris
···
On May 2, 2016, at 1:19 PM, John McCall <rjmccall@apple.com> wrote:
On May 2, 2016, at 12:13 PM, Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@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.
On May 2, 2016, at 2:35 PM, Chris Lattner <clattner@apple.com> wrote:
On May 2, 2016, at 1:19 PM, John McCall <rjmccall@apple.com <mailto:rjmccall@apple.com>> wrote:
On May 2, 2016, at 12:13 PM, Антон Жилин <antonyzhilin@gmail.com <mailto:antonyzhilin@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.
Unless there is some “new information”, I don’t see any reason to waste the communities time on this.
I wouldn't say it "didn't work out in practice." It's not like we ran into some design/implementation hurdle that we weren't expecting. We had adopters who were annoyed at having to make a pervasive change by hand that they felt wasn't an improvement. I felt then (and continue to feel) that it would have been fine if we had spelled it with a question mark to begin with; but since we didn't, it was seen as a pointless regression in the amount of punctuation in Swift code, which was a very sensitive topic at the time.
And you know, that's okay. Language design is design, not art; our goal here is to make a great tool that helps people, not to make a perfect self-consistent expression of an idea. If we can do both, wonderful, but if we can't, well, it's pretty nice to have users.
John.
···
On May 2, 2016, at 2:17 PM, David Hart <david@hartbit.com> wrote:
John,
When the core team implemented the `if let x? = y` experiment and later backtracked, were you enthusiastic about it? The way Jordan puts it "Yeah, as nice as it sounds, it didn’t work out in practice.” sounds very definite, as if it was an obvious and unanimous decision to backtrack.