[Accepted with Revision] SE-0099 Restructuring Condition Clauses

Evolution Announcements
1

The review of SE-0099 "Restructuring Condition Clauses" ran from January 13...18, 2016. The proposal has been accepted with revision for Swift 3. There was near unanimous agreement that the Swift 2 grammar was inconsistent and ambiguous and should be changed; most of the disagreement centered on how. Many alternatives were discussed, including the following:

- The proposal as written suggests using ';' or newline as a separator. To many people, this looked heavy, and it's also inconsistent with the rest of the language, which never otherwise used semicolon as an intra-statement separator (except in the defunct for;; loop).
- Introducing a keyword separator, such as using 'where' everywhere or introducing a new 'and' keyword, is also bulky and either reads poorly or requires stealing new keywords.
- Some commenters suggested using '&&' for consistency with simple boolean conditions. This isn't workable due to precedence issues.
- The ambiguities arise from the fact that there are comma-separated lists within comma-separated lists—within the list of conditions, each 'case' or 'let' condition can have multiple declarations. If we eliminated this feature, so that every 'case' or 'let' condition had to start with 'case' or 'let', the ambiguity is resolved, and comma can remain the condition separator. This does break consistency with non-conditional 'let' declarations and case clauses in 'switch' but is otherwise workable.

Of these alternatives, the core team found the last one to be the best choice. 'case' and 'let' conditions should each specify a single declaration, comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer. Some code becomes more verbose, but in common formatting patterns, it aligns more nicely, as in:

  guard
    let x = foo(),
    let y = bar(),
    let z = bas(),
    x == y || y == z else {
  }

and though it breaks commonality between 'let' conditions and 'let' declarations, it's more important to preserve higher-level consistency throughout the language in how components of expressions and statements are separated. Thanks everyone for the discussion, and thanks Erica and Chris for the proposal! Since, aside from the approved syntax, the fundamental thrust of the proposal remains the same, Chris has volunteered to revise it to be in line with the approved decision.

-Joe

2

Of these alternatives, the core team found the last one to be the best choice. 'case' and 'let' conditions should each specify a single declaration, comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer. Some code becomes more verbose, but in common formatting patterns, it aligns more nicely, as in:

  guard
    let x = foo(),
    let y = bar(),
    let z = bas(),
    x == y || y == z else {
  }

and though it breaks commonality between 'let' conditions and 'let' declarations, it's more important to preserve higher-level consistency throughout the language in how components of expressions and statements are separated.

I think this is a pretty good way to split the baby, especially because it actually improves an issue which always led to awkward indentation problems.

Even with this change, I believe you'll be able to avoid redundant `case` keywords by using tuples:

  guard case (.none, .none, .none) = (foo(), bar(), bas()) else {

However, if-let does not permit the analogous construct:

  guard let (x, y, z) = (foo(), bar(), bas()) else {

Now that we're moving away from allowing compound if-lets, I think it might be a good idea to revisit that decision. Would this be better handled as a separate proposal?

···

--
Brent Royal-Gordon
Architechies

3

I am deeply saddened that a little part of character is lost in swift with the removal of where (imo). But I can be happy that ; is not being used I guess.

My question: what is/was the rationale for adding where to swift 2? We seem to just be removing it everywhere now (or at least the proposals will be incoming)

Brandon

···

Sent from my iPad

On Jun 8, 2016, at 9:47 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

The review of SE-0099 "Restructuring Condition Clauses" ran from January 13...18, 2016. The proposal has been accepted with revision for Swift 3. There was near unanimous agreement that the Swift 2 grammar was inconsistent and ambiguous and should be changed; most of the disagreement centered on how. Many alternatives were discussed, including the following:

- The proposal as written suggests using ';' or newline as a separator. To many people, this looked heavy, and it's also inconsistent with the rest of the language, which never otherwise used semicolon as an intra-statement separator (except in the defunct for;; loop).
- Introducing a keyword separator, such as using 'where' everywhere or introducing a new 'and' keyword, is also bulky and either reads poorly or requires stealing new keywords.
- Some commenters suggested using '&&' for consistency with simple boolean conditions. This isn't workable due to precedence issues.
- The ambiguities arise from the fact that there are comma-separated lists within comma-separated lists—within the list of conditions, each 'case' or 'let' condition can have multiple declarations. If we eliminated this feature, so that every 'case' or 'let' condition had to start with 'case' or 'let', the ambiguity is resolved, and comma can remain the condition separator. This does break consistency with non-conditional 'let' declarations and case clauses in 'switch' but is otherwise workable.

Of these alternatives, the core team found the last one to be the best choice. 'case' and 'let' conditions should each specify a single declaration, comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer. Some code becomes more verbose, but in common formatting patterns, it aligns more nicely, as in:

  guard
    let x = foo(),
    let y = bar(),
    let z = bas(),
    x == y || y == z else {
  }

and though it breaks commonality between 'let' conditions and 'let' declarations, it's more important to preserve higher-level consistency throughout the language in how components of expressions and statements are separated. Thanks everyone for the discussion, and thanks Erica and Chris for the proposal! Since, aside from the approved syntax, the fundamental thrust of the proposal remains the same, Chris has volunteered to revise it to be in line with the approved decision.

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

Can we get some clarification as to why ‘where’ is being chosen to be retired here? I’m deeply disappointed by that decision as enabling the consistent use of comma as a separator does not preclude the use of where for simple cases that don’t require it. I’m all for having a more usable separator for complex conditionals, but I rarely need it, meanwhile in common, simple conditional bindings and patterns I find the ‘where’ keyword a lot more readable, i.e:

  if let value = foo where foo > 5 { … }
  if let value = foo, foo > 5 { … }

The latter just doesn’t read as cleanly to me, and these are the kinds of simple conditionals that I use a lot of. As such as I’d still prefer to have ‘where’ be usable in the simple case, and I feel it was a mistake for the SE-0099 to have it tied to changes to the separator as the two changes aren’t mutually exclusive.

···

On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer.

5

A concern that I have with this is that comma seems to get inconsistent treatment in the language. In conditionals, commas clearly represent conjunctive clauses. However, the core team has also argued (review of SE-0095) that usage of comma implies disjunction and proposes that ‚&‘ is used for specifying intersection (conjunction) of types. So which is it? If we want to be 100% consistent, we should either adopt commas as conjunction through the language, or, use &/&& for conjunction. Personally, I have no problems accepting commas as conjunction.

— Taras

···

On 09 Jun 2016, at 03:47, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

The review of SE-0099 "Restructuring Condition Clauses" ran from January 13...18, 2016. The proposal has been accepted with revision for Swift 3. There was near unanimous agreement that the Swift 2 grammar was inconsistent and ambiguous and should be changed; most of the disagreement centered on how. Many alternatives were discussed, including the following:

- The proposal as written suggests using ';' or newline as a separator. To many people, this looked heavy, and it's also inconsistent with the rest of the language, which never otherwise used semicolon as an intra-statement separator (except in the defunct for;; loop).
- Introducing a keyword separator, such as using 'where' everywhere or introducing a new 'and' keyword, is also bulky and either reads poorly or requires stealing new keywords.
- Some commenters suggested using '&&' for consistency with simple boolean conditions. This isn't workable due to precedence issues.
- The ambiguities arise from the fact that there are comma-separated lists within comma-separated lists—within the list of conditions, each 'case' or 'let' condition can have multiple declarations. If we eliminated this feature, so that every 'case' or 'let' condition had to start with 'case' or 'let', the ambiguity is resolved, and comma can remain the condition separator. This does break consistency with non-conditional 'let' declarations and case clauses in 'switch' but is otherwise workable.

Of these alternatives, the core team found the last one to be the best choice. 'case' and 'let' conditions should each specify a single declaration, comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer. Some code becomes more verbose, but in common formatting patterns, it aligns more nicely, as in:

  guard
    let x = foo(),
    let y = bar(),
    let z = bas(),
    x == y || y == z else {
  }

and though it breaks commonality between 'let' conditions and 'let' declarations, it's more important to preserve higher-level consistency throughout the language in how components of expressions and statements are separated. Thanks everyone for the discussion, and thanks Erica and Chris for the proposal! Since, aside from the approved syntax, the fundamental thrust of the proposal remains the same, Chris has volunteered to revise it to be in line with the approved decision.

-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

6

Yes, this should be a follow up pitch/proposal. Thanks Brent,

-Chris

···

On Jun 8, 2016, at 7:27 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

However, if-let does not permit the analogous construct:

  guard let (x, y, z) = (foo(), bar(), bas()) else {

Now that we're moving away from allowing compound if-lets, I think it might be a good idea to revisit that decision. Would this be better handled as a separate proposal?

7

Can we get some clarification as to why ‘where’ is being chosen to be retired here? I’m deeply disappointed by that decision as enabling the consistent use of comma as a separator does not preclude the use of where for simple cases that don’t require it. I’m all for having a more usable separator for complex conditionals, but I rarely need it, meanwhile in common, simple conditional bindings and patterns I find the ‘where’ keyword a lot more readable, i.e:

  if let value = foo where foo > 5 { … }

I think there may be a case for keeping the `where` keyword—but before, not after, the equals sign.

  if case .cartesian(let x, let y) where x != y = point { ... }
  if let value where value > 5 = foo { ... }

Why? Consistency with other `case` statements. I recently made the same point about `for` loops: `where` is part of the pattern-matching syntax, and it ought to be attached to the pattern it refines. Letting it float into other parts of the statement unmoors it from its meaning.

That will probably read strangely for some current uses of `where`—specifically, ones that have a condition unconnected to the preceding pattern—but that's when you should use a comma to introduce a separate Boolean condition clause instead. Personally, I think the `if let value` example above would probably be more appropriate as a Boolean condition clause, but tastes differ.

···

--
Brent Royal-Gordon
Architechies

8

The clarification seems pretty clear to me, and they stated it:

"to preserve higher-level consistency throughout the language in how components of expressions and statements are separated"

···

On 09 Jun 2016, at 09:53, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer.

Can we get some clarification as to why ‘where’ is being chosen to be retired here? I’m deeply disappointed by that decision as enabling the consistent use of comma as a separator does not preclude the use of where for simple cases that don’t require it. I’m all for having a more usable separator for complex conditionals, but I rarely need it, meanwhile in common, simple conditional bindings and patterns I find the ‘where’ keyword a lot more readable, i.e:

  if let value = foo where foo > 5 { … }
  if let value = foo, foo > 5 { … }

The latter just doesn’t read as cleanly to me, and these are the kinds of simple conditionals that I use a lot of. As such as I’d still prefer to have ‘where’ be usable in the simple case, and I feel it was a mistake for the SE-0099 to have it tied to changes to the separator as the two changes aren’t mutually exclusive.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer.

Can we get some clarification as to why ‘where’ is being chosen to be retired here? I’m deeply disappointed by that decision as enabling the consistent use of comma as a separator does not preclude the use of where for simple cases that don’t require it. I’m all for having a more usable separator for complex conditionals, but I rarely need it, meanwhile in common, simple conditional bindings and patterns I find the ‘where’ keyword a lot more readable, i.e:

  if let value = foo where foo > 5 { … }
  if let value = foo, foo > 5 { … }

FWIW huge amounts of complex golang code have managed to exist with the latter syntax. I had difficulties with it when I started (I'm c,c++,java,c#,js,ts), but these days I would no longer question it.

···

On Jun 9, 2016, at 9:53 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

The latter just doesn’t read as cleanly to me, and these are the kinds of simple conditionals that I use a lot of. As such as I’d still prefer to have ‘where’ be usable in the simple case, and I feel it was a mistake for the SE-0099 to have it tied to changes to the separator as the two changes aren’t mutually exclusive.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

I have just one last thing to say on this topic as it is clear it is going into the language and no accepted proposal has been overturned that I am aware of.

I believe with this cycle, the swift evolution process didn't work.

And here is why I think this:
- This proposal began as a discussion on May 20th and lasted 4 days with minimal discussion outside of a few people
- The review period was then fast tracked and began 3 days after discussion ended (May 27th)
- The review period technically ended on June 3rd
- Approved with revision on June 8th

From May 20th to June 8th (and probably before because it was clear this was getting approved earlier) we have proposed, revised, and accepted a far reaching syntactic change. Presumably we will be stuck with this behavior for a long time or forever. This effects more than just the few that participated in the discussion: it effects every swift user.

I think this happened too fast. I do not believe we got an adequate pulse of the broader swift community.

What we got was very technical and proficient user feedback. When phrases like "making the language more consistent", why wouldn't these developers want to approve it? This is the kind of stuff people deeply involved in the language care about. I am not sure that reflects the entire community.

What about the more common developer who isn't as technically skilled yet? This has huge changes for them too and I barely heard any of their voices...at least publicly. This has big usability changes for them.

On top of this, we have a new revised syntax that somewhat meets in the middle of both sides. However, does meeting in the middle make this all better just for the sake of consistency? Should we have an extended review period for this proposed change or do we just accept it?

My TLDR overview:
- Discussion and proposal moved extremely fast. We only heard feedback from the more proficient developers and not necessarily the "common" developer...which this arguably effects more. The technically skilled can always adapt and of course always prefers a more consistent language...but do most developers feel this way? They just want a usable and expressive language
- WWDC is in a few days. We will get a flood of people from all different backgrounds: newbies to the very skilled. My prediction: there will be backlash from this proposal once more people know about it.

I believe large syntax changes should have more discussion from more developers and not a very small subset of them. The review announcement needs to be broader: the swift blog needs to announce it so more people know. Not everyone is on the mailing list...because frankly it can be daunting for us who aren't as skilled as the others on here.

Do I believe that the smartest people can design a great language on their own? No.

It is generally understood that most developers don't fully understand UX or the end users using their stuff. I feel this is what has happened with this proposal. It sounded good because it was all for the sake of "consistency". However, I believe the end user will ultimately be disappointed with the loss of expressivity.

Maybe I am wrong. I hope I am wrong...but I feel we will not here the end of this after WWDC begins.

And because of that, this is why I feel the swift evolution process did not work properly in this case. (And really I have this same with other fast tracked proposals now).

Really TLDR: I believe these large syntax proposals need broader feedback from the community and not a small subset of the top swift developers.

How do we pull more people in for these discussions? I don't know, but more announcements on the blog and from Swift on Twitter

Sorry for the long post, but I just wanted to express my concerns for a language I was growing to really love!
Brandon

···

Sent from my iPad

On Jun 9, 2016, at 3:53 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer.

Can we get some clarification as to why ‘where’ is being chosen to be retired here? I’m deeply disappointed by that decision as enabling the consistent use of comma as a separator does not preclude the use of where for simple cases that don’t require it. I’m all for having a more usable separator for complex conditionals, but I rarely need it, meanwhile in common, simple conditional bindings and patterns I find the ‘where’ keyword a lot more readable, i.e:

  if let value = foo where foo > 5 { … }
  if let value = foo, foo > 5 { … }

The latter just doesn’t read as cleanly to me, and these are the kinds of simple conditionals that I use a lot of. As such as I’d still prefer to have ‘where’ be usable in the simple case, and I feel it was a mistake for the SE-0099 to have it tied to changes to the separator as the two changes aren’t mutually exclusive.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

11

That looks pretty strange visually though thanks to the assignment (it kind of looks like x is being compared against y = point). It works better as you proposed in a for where in loop since the in keyword keeps it separated nicely. Even so, I prefer where coming after as it makes the condition secondary to what it is I want to do, e.g- I want to bind a condition, but only if the where clause succeeds.

While my reasons for liking where are mainly aesthetic once the need to use it to get around separator issues goes away, it’s still a nice tool for grouping statements visually, for example:

  if let foo = maybeFoo where foo > 5, let bar = maybeBar where bar < 100 { … }

Versus:

  if let foo = maybeFoo, foo > 5, let bar = maybeBar, bar < 100 { … }

Even splitting these across two lines I prefer how the where clauses look in terms of specifically indicating that the binding and condition are related/distinct from the other pair. While I get that in this case it doesn’t functionally do anything that the comma doesn’t, I’m not sure I agree that it should be dropped as I’m perfectly capable of choosing for myself which to use for my conditionals, and I prefer how the where looks visually in terms of implying a direct relationship.

···

On 9 Jun 2016, at 09:47, Brent Royal-Gordon <brent@architechies.com> wrote:

Can we get some clarification as to why ‘where’ is being chosen to be retired here? I’m deeply disappointed by that decision as enabling the consistent use of comma as a separator does not preclude the use of where for simple cases that don’t require it. I’m all for having a more usable separator for complex conditionals, but I rarely need it, meanwhile in common, simple conditional bindings and patterns I find the ‘where’ keyword a lot more readable, i.e:

  if let value = foo where foo > 5 { … }

I think there may be a case for keeping the `where` keyword—but before, not after, the equals sign.

  if case .cartesian(let x, let y) where x != y = point { ... }
  if let value where value > 5 = foo { … }

12

Sorry about the immediate followup, but I just recalled you mentioned multiple conditional binding, which would have brackets, so what about the following:

  if case .cartesian(let x, let y where x != y) = point { … }
  if let (value where value > 5) = foo { … }
  if let (foo, bar where foo > 5) = (maybeFoo, maybeBar) { … }

While it requires brackets for the single conditional binding (you could still drop them with no where clause though) it seems easier to read to me. For consistency this would probably apply to your for loop suggestion like:

  for (eachValue where eachValue > 5) in theValues { … }

···

On 9 Jun 2016, at 09:47, Brent Royal-Gordon <brent@architechies.com> wrote:

Can we get some clarification as to why ‘where’ is being chosen to be retired here? I’m deeply disappointed by that decision as enabling the consistent use of comma as a separator does not preclude the use of where for simple cases that don’t require it. I’m all for having a more usable separator for complex conditionals, but I rarely need it, meanwhile in common, simple conditional bindings and patterns I find the ‘where’ keyword a lot more readable, i.e:

  if let value = foo where foo > 5 { … }

  if case .cartesian(let x, let y) where x != y = point { ... }
  if let value where value > 5 = foo { ... }

13

Like the flounder and the human appendix, it was a vestige of incomplete evolution. Our current design emerged from an original design that attempted to unify "switch"-style pattern matching and "let"-style destructuring, the idea being that '<pattern> = <value>' should work for patterns that never fail to match, such as variable bindings and tuples, as a special case of 'switch <value> { case <pattern> where <condition>: }' or 'if <pattern> = <value> where <condition>', which would allow for arbitrary conditional pattern matching. We ultimately didn't go in that direction after getting strong negative feedback from our internal adopters, who had grown accustomed to the 'if let' sugar for optional binding.

-Joe

···

On Jun 9, 2016, at 12:53 AM, Haravikk <swift-evolution@haravikk.me> wrote:

On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer.

Can we get some clarification as to why ‘where’ is being chosen to be retired here? I’m deeply disappointed by that decision as enabling the consistent use of comma as a separator does not preclude the use of where for simple cases that don’t require it. I’m all for having a more usable separator for complex conditionals, but I rarely need it, meanwhile in common, simple conditional bindings and patterns I find the ‘where’ keyword a lot more readable, i.e:

  if let value = foo where foo > 5 { … }
  if let value = foo, foo > 5 { … }

The latter just doesn’t read as cleanly to me, and these are the kinds of simple conditionals that I use a lot of. As such as I’d still prefer to have ‘where’ be usable in the simple case, and I feel it was a mistake for the SE-0099 to have it tied to changes to the separator as the two changes aren’t mutually exclusive.

14

I believe large syntax changes should have more discussion from more developers and not a very small subset of them. The review announcement needs to be broader: the swift blog needs to announce it so more people know.

No.

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal. Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

···

--
Brent Royal-Gordon
Architechies

15

I believe large syntax changes should have more discussion from more developers and not a very small subset of them. The review announcement needs to be broader: the swift blog needs to announce it so more people know.

No.

Grrrr

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

I think your perspective is flawed here. You are precisely one of the "top developers" I have been referring to. Am I surprised this is your opinion? Not one bit.

Mailing lists are a rather old thing...and I think many will find them daunting or maybe somewhat annoying with all of the announcements. How many people are subscribed to announce? It does not seem like many because well...we don't always get a lot of feedback. We get feedback from the same people over and over. How is this enough? How is this enough variety?

Just because "announce" is more palatable does not mean that it is being used in the way you are describing.

Maybe there is another problem then: people afraid to share their opinions publicly. I wonder why this would be.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

Why do people keep saying I am asking for: "hundreds or thousands" of reviews? I am just asking for something like 20 - 25 unique people's feedback. We are not getting that. We get the same people over and over...which makes the feedback seem screwed to this small group's philosophies.

Getting feedback from the same ~10 people is not a "reasonable variety of eyes" in my opinion. That is a very small sample. And that sample is usually those who are very technically skilled...who I would say do not always design the best interfaces.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

I think you will be very surprised come WWDC when people learn of this change.

How is there value when the same people keep justifying changes for the sake of consistency? Is this in the user's best interest? Or is this in the swift engineer's best interest?

This is precisely why I think more feedback is important. We need more than just the same people propping up proposals that gives an illusion that it is representative of everyone using swift.

The bar should be high for changing syntax, so I don't buy the argument that 25 people sharing their feedback is somehow less valuable than 10 people sharing.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal.

I don't think this was though through thoroughly enough. It just happened too fast

Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

Maybe you are right. Maybe I am vastly wrong. But I guess this will be clearer come WWDC.

And I already know how the people complaining about this change will be silenced: it was done for the consistency of the language and the grammar.

How can us simpletons argue against that?

Also, I want to make clear that my concern is not just for this review but for future reviews also. How different could the language look with more varied feedback?

Again, I hope I am wrong =/
Brandon

···

Sent from my iPad
On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

--
Brent Royal-Gordon
Architechies

16

From the original thread:

<snip>

It does occur to me that there is one more option. I don't know that I like it, but it's an option no one has put forward before: recite the opening keyword when beginning a new boolean expression:

`if let x = x where x < 3 { ... }` becomes
`if let x = x if x < 3 { ... }`

`while let item = sequence.next() where item > 0 { ... }` becomes
`while let item = sequence.next() while item > 0 { ... }`

etc.

I've almost had the same idea... However I would not replace "where" rather than using if/while/guard as delimiters for new optional bindings/case-conditions:

// if ----------------------
if let x = y where x < 4,
if case let .some(a) = b where a > 42 {
   ...
}

// Is equivalent to:

if let x = y where x < 4 {
   if case let .some(a) = b where a > 42 {
       ...
   }
}

// guard ----------------------
guard let x = y where x < 4,
guard case let .some(a) = b where a > 42 else { ... }

// Is equivalent to:

guard let x = y where x < 4 else { ... }
guard case let .some(a) = b where a > 42 else { ... }

// while ----------------------

// "guard" or "if" should probably be used as delimiter instead of "while"
// since it is not a nested loop (imo I would go with "if"... discussable...)
while let x = y where x < 4,
while case let .some(a) = b where a > 42 {
  ...
}

// Is equivalent to:

while let x = y where x < 4 {
   guard case let .some(a) = b where a > 42 else {
       break
   }
   do { ... }
}

// or with if

while let x = y where x < 4 {
   if case let .some(a) = b where a > 42 {
       ...
   } else { break }
}

Note that all these statements have a nice symmetry to their "long form". These statements can also be similarly written without introducing a new scope and code duplication in else branches:

if ...
if ... {
   ...
} else { ... }

vs

if ... {
   if ... {
       ...
   } else { ... }
} else { ... }

Best regards
Maximilian

···

Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution <swift-evolution@swift.org>:

17

I don't know what your professional experience in the software industry is, but mine is that design by conscensus rarely leads to the best outcome, especially in the presence of strong egos. Swift is advertised as Opinionated, but (fortunately) nowhere does it say your or my opinion. I would even go so far as to say that most people can't design a language to save their lives (me included). At some point, a small number of benevolent dictators have to make a decision they believe in.

IMO the job of the community is to shake ideas in front of these dictators with the hope that it will give perspectives they may not have already seen, or challenge their ideas in ways they might not have anticipated. But nowhere does it say (and I will immediately drop any further interest in Swift if someone tells me it should be that way) that their role is to dutifully record what the plebe wants and deliver it as best as they can. Taken together, some of the most individually popular suggestions would undoubtedly lead to some sort of franken-swift that not even the people pushing these ideas forward would end up using.

···

On Jun 9, 2016, at 4:34 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

I have just one last thing to say on this topic as it is clear it is going into the language and no accepted proposal has been overturned that I am aware of.

I believe with this cycle, the swift evolution process didn't work.

And here is why I think this:
- This proposal began as a discussion on May 20th and lasted 4 days with minimal discussion outside of a few people
- The review period was then fast tracked and began 3 days after discussion ended (May 27th)
- The review period technically ended on June 3rd
- Approved with revision on June 8th

From May 20th to June 8th (and probably before because it was clear this was getting approved earlier) we have proposed, revised, and accepted a far reaching syntactic change. Presumably we will be stuck with this behavior for a long time or forever. This effects more than just the few that participated in the discussion: it effects every swift user.

I think this happened too fast. I do not believe we got an adequate pulse of the broader swift community.

What we got was very technical and proficient user feedback. When phrases like "making the language more consistent", why wouldn't these developers want to approve it? This is the kind of stuff people deeply involved in the language care about. I am not sure that reflects the entire community.

What about the more common developer who isn't as technically skilled yet? This has huge changes for them too and I barely heard any of their voices...at least publicly. This has big usability changes for them.

On top of this, we have a new revised syntax that somewhat meets in the middle of both sides. However, does meeting in the middle make this all better just for the sake of consistency? Should we have an extended review period for this proposed change or do we just accept it?

My TLDR overview:
- Discussion and proposal moved extremely fast. We only heard feedback from the more proficient developers and not necessarily the "common" developer...which this arguably effects more. The technically skilled can always adapt and of course always prefers a more consistent language...but do most developers feel this way? They just want a usable and expressive language
- WWDC is in a few days. We will get a flood of people from all different backgrounds: newbies to the very skilled. My prediction: there will be backlash from this proposal once more people know about it.

I believe large syntax changes should have more discussion from more developers and not a very small subset of them. The review announcement needs to be broader: the swift blog needs to announce it so more people know. Not everyone is on the mailing list...because frankly it can be daunting for us who aren't as skilled as the others on here.

Do I believe that the smartest people can design a great language on their own? No.

It is generally understood that most developers don't fully understand UX or the end users using their stuff. I feel this is what has happened with this proposal. It sounded good because it was all for the sake of "consistency". However, I believe the end user will ultimately be disappointed with the loss of expressivity.

Maybe I am wrong. I hope I am wrong...but I feel we will not here the end of this after WWDC begins.

And because of that, this is why I feel the swift evolution process did not work properly in this case. (And really I have this same with other fast tracked proposals now).

Really TLDR: I believe these large syntax proposals need broader feedback from the community and not a small subset of the top swift developers.

How do we pull more people in for these discussions? I don't know, but more announcements on the blog and from Swift on Twitter

Sorry for the long post, but I just wanted to express my concerns for a language I was growing to really love!
Brandon

Sent from my iPad

On Jun 9, 2016, at 3:53 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer.

Can we get some clarification as to why ‘where’ is being chosen to be retired here? I’m deeply disappointed by that decision as enabling the consistent use of comma as a separator does not preclude the use of where for simple cases that don’t require it. I’m all for having a more usable separator for complex conditionals, but I rarely need it, meanwhile in common, simple conditional bindings and patterns I find the ‘where’ keyword a lot more readable, i.e:

  if let value = foo where foo > 5 { … }
  if let value = foo, foo > 5 { … }

The latter just doesn’t read as cleanly to me, and these are the kinds of simple conditionals that I use a lot of. As such as I’d still prefer to have ‘where’ be usable in the simple case, and I feel it was a mistake for the SE-0099 to have it tied to changes to the separator as the two changes aren’t mutually exclusive.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

18

Goodbye semi-column, goodbye multi-let.... i will mourne you. :( .... hello reasonable improvement

···

On Jun 9, 2016, at 5:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

I believe large syntax changes should have more discussion from more developers and not a very small subset of them. The review announcement needs to be broader: the swift blog needs to announce it so more people know.

No.

Firstly, for those who cannot follow the list—and I can't say I blame them—the -announce list already allows them to ignore everything except the beginnings of reviews. Anyone who wants to (and who speaks English) can be notified of any significant proposed change to the language and can submit their comments for the core team's consideration. That is enough.

The purpose of reviews is not to cast ballots for or against a feature. It is to submit arguments, for and against, for the core team to consider as they decide whether and how to address the problem the proposal's "Motivation" section describes. For that purpose, there is no need to collect hundreds or thousands of reviews, and if we did, the review manager would be swamped anyway. It is enough to get a reasonable variety of eyes, from a reasonable variety of perspectives, on the problem.

I think that has happened here. We have not heard from every perspective, but we have heard from enough of them that adding more will not help all that much. Feedback always has diminishing returns: going from one person to two is far more valuable than going from fifty-one to fifty-two.

And in particular, I *don't* think the beginner perspective is an especially worrisome one for this particular proposal. Though some of the syntaxes we considered might have been confusing for beginners (*cough*semicolon*cough*), the one the core team settled in is actually one of the simplest, and certainly much simpler than the status quo. If anything, the people most disadvantaged by this solution are the power users who are used to the "multiple if-let" shorthand and will now have to add extra keywords to their code.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

19

While I did not get a chance to review all the discussion in time to
respond to the proposal, I am happy with the revised version that was
approved (the semi-colons were a point of concern for me). In addition
to resolving ambiguity, this also resolved a pedigogical issue
surrounding the 'where' keyword I encountered when teaching Swift.

'where' keyword can be retired from its purpose as a boolean condition
introducer.

When teaching Swift, I did discover that the requirement of 'where' in
conditionals as expressed by this proposal was confusing and those I was
teaching assumed they would use commas (or &&).

I'll admit that at first the 'where' keyword surprised me as well, but I
grew to like it and will be a little sad to see it replaced by comma
instead of allowing 'where' or comma as I thought certain statements
were easier to read with 'where'.

        Can we get some clarification as to why ‘where’ is being chosen
        to be retired here? I’m deeply disappointed by that decision as
        enabling the consistent use of comma as a separator does not
        preclude the use of where for simple cases that don’t require
        it. I’m all for having a more usable separator for complex
        conditionals, but I rarely need it, meanwhile in common, simple
        conditional bindings and patterns I find the ‘where’ keyword a
        lot more readable, i.e:
        
        if let value = foo where foo > 5 { … }
        
    I think there may be a case for keeping the `where` keyword—but
    before, not after, the equals sign.
    
    if case .cartesian(let x, let y) where x != y = point { ... }
    if let value where value > 5 = foo { … }
    
That looks pretty strange visually though thanks to the assignment (it
kind of looks like x is being compared against y = point).

I had this feeling as well.

While my reasons for liking where are mainly aesthetic once the need to
use it to get around separator issues goes away, it’s still a nice tool
for grouping statements visually, for example:

This is the case for me as well, functionally I suppose I will not miss
'where', but for aesthetics I do think it made some statements cmore
clear to read.

···

On Wed, Jun 08 2016 at 09:47:55 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Thu, Jun 09 2016 at 06:30:17 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

    On 9 Jun 2016, at 09:47, Brent Royal-Gordon > <brent@architechies.com> wrote:

--
Roth

20

I share the concern of this being a weakness of the process, but I don’t know what the alternative is (besides shutting it down and sealing the sausage-making back inside of Apple where we can’t see it :P)

I do think, though, that perhaps in the future maybe there should be a moratorium on reviews 2 weeks or so prior and post WWDC - anyone at Apple is swamped during this time period and I suspect it doesn’t do anyone any good to dramatically change the language weeks before thousands of people tune in to learn what’s new only to find that after they start getting final Xcode builds in the fall, everything has changed again. :/

l8r
Sean

···

On Jun 9, 2016, at 9:59 AM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

I never said design by consensus. What I said is that we did not have a broader representation during this review.

What we got was a few "top" developers sharing their opinion. To me this is not healthy. We needed more opinions from the top skilled developers to hobbyists.

Maybe this wouldn't have changed the outcome, but it could have guided the discussion more and perhaps differently.

The core team *is* taking feedback from the community. This feedback however is from a few very technically skilled developers and not necessarily representative of the more common developer (of which there is more).

The fact that this proposal and review went through so quickly makes me suspect whether all of the ramifications were thought through thoroughly.

The core team is wonderful, so I am sure they awesome discussions on this...but the fact that it happened so quickly is worrisome to me.

I hope developers like me have somewhat of an advocate on the core team as I am sure everyone on that team is in the very highly skilled category :P

Brandon

Sent from my iPad

On Jun 9, 2016, at 10:51 AM, L. Mihalkovic <laurent.mihalkovic@gmail.com> wrote:

I don't know what your professional experience in the software industry is, but mine is that design by conscensus rarely leads to the best outcome, especially in the presence of strong egos. Swift is advertised as Opinionated, but (fortunately) nowhere does it say your or my opinion. I would even go so far as to say that most people can't design a language to save their lives (me included). At some point, a small number of benevolent dictators have to make a decision they believe in.

IMO the job of the community is to shake ideas in front of these dictators with the hope that it will give perspectives they may not have already seen, or challenge their ideas in ways they might not have anticipated. But nowhere does it say (and I will immediately drop any further interest in Swift if someone tells me it should be that way) that their role is to dutifully record what the plebe wants and deliver it as best as they can. Taken together, some of the most individually popular suggestions would undoubtedly lead to some sort of franken-swift that not even the people pushing these ideas forward would end up using.

On Jun 9, 2016, at 4:34 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

I have just one last thing to say on this topic as it is clear it is going into the language and no accepted proposal has been overturned that I am aware of.

I believe with this cycle, the swift evolution process didn't work.

And here is why I think this:
- This proposal began as a discussion on May 20th and lasted 4 days with minimal discussion outside of a few people
- The review period was then fast tracked and began 3 days after discussion ended (May 27th)
- The review period technically ended on June 3rd
- Approved with revision on June 8th

From May 20th to June 8th (and probably before because it was clear this was getting approved earlier) we have proposed, revised, and accepted a far reaching syntactic change. Presumably we will be stuck with this behavior for a long time or forever. This effects more than just the few that participated in the discussion: it effects every swift user.

I think this happened too fast. I do not believe we got an adequate pulse of the broader swift community.

What we got was very technical and proficient user feedback. When phrases like "making the language more consistent", why wouldn't these developers want to approve it? This is the kind of stuff people deeply involved in the language care about. I am not sure that reflects the entire community.

What about the more common developer who isn't as technically skilled yet? This has huge changes for them too and I barely heard any of their voices...at least publicly. This has big usability changes for them.

On top of this, we have a new revised syntax that somewhat meets in the middle of both sides. However, does meeting in the middle make this all better just for the sake of consistency? Should we have an extended review period for this proposed change or do we just accept it?

My TLDR overview:
- Discussion and proposal moved extremely fast. We only heard feedback from the more proficient developers and not necessarily the "common" developer...which this arguably effects more. The technically skilled can always adapt and of course always prefers a more consistent language...but do most developers feel this way? They just want a usable and expressive language
- WWDC is in a few days. We will get a flood of people from all different backgrounds: newbies to the very skilled. My prediction: there will be backlash from this proposal once more people know about it.

I believe large syntax changes should have more discussion from more developers and not a very small subset of them. The review announcement needs to be broader: the swift blog needs to announce it so more people know. Not everyone is on the mailing list...because frankly it can be daunting for us who aren't as skilled as the others on here.

Do I believe that the smartest people can design a great language on their own? No.

It is generally understood that most developers don't fully understand UX or the end users using their stuff. I feel this is what has happened with this proposal. It sounded good because it was all for the sake of "consistency". However, I believe the end user will ultimately be disappointed with the loss of expressivity.

Maybe I am wrong. I hope I am wrong...but I feel we will not here the end of this after WWDC begins.

And because of that, this is why I feel the swift evolution process did not work properly in this case. (And really I have this same with other fast tracked proposals now).

Really TLDR: I believe these large syntax proposals need broader feedback from the community and not a small subset of the top swift developers.

How do we pull more people in for these discussions? I don't know, but more announcements on the blog and from Swift on Twitter

Sorry for the long post, but I just wanted to express my concerns for a language I was growing to really love!
Brandon

Sent from my iPad

On Jun 9, 2016, at 3:53 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

comma should remain the condition separator, and the 'where' keyword can be retired from its purpose as a boolean condition introducer.

Can we get some clarification as to why ‘where’ is being chosen to be retired here? I’m deeply disappointed by that decision as enabling the consistent use of comma as a separator does not preclude the use of where for simple cases that don’t require it. I’m all for having a more usable separator for complex conditionals, but I rarely need it, meanwhile in common, simple conditional bindings and patterns I find the ‘where’ keyword a lot more readable, i.e:

  if let value = foo where foo > 5 { … }
  if let value = foo, foo > 5 { … }

The latter just doesn’t read as cleanly to me, and these are the kinds of simple conditionals that I use a lot of. As such as I’d still prefer to have ‘where’ be usable in the simple case, and I feel it was a mistake for the SE-0099 to have it tied to changes to the separator as the two changes aren’t mutually exclusive.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution