[Review] SE-0099: Restructuring Condition Clauses

Joe_Groff · May 27, 2016, 7:11pm

Hello Swift community,

The review of SE-0099 “Restructuring Condition Clauses” begins now and runs through June 3, 2016. The proposal is available here:

swift-evolution/0099-conditionclauses.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

swift-evolution/0099-conditionclauses.md at master · apple/swift-evolution · GitHub

Reply text

Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Joe

Review Manager

anandabits · May 27, 2016, 7:28pm

• What is your evaluation of the proposal?

+1. I believe it improves the clarity of condition clauses and as the proposal suggests, I think it will make it easier for programmers to learn and understand what is possible with them.

Did you consider allowing the semicolon to be omitted when a newline separates conditions? Something like this:

If so, what is the reason for requiring semicolons here when they can be omitted elsewhere in Swift?

• Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

• Does this proposal fit well with the feel and direction of Swift?

Yes.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Participated in the discussion and offered feedback along the way, as well as reading the final proposal.

···

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe

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

Brent_Royal-Gordon · May 27, 2016, 11:35pm

https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

• What is your evaluation of the proposal?

Oof.

I am not a fan of this syntax. `;` reads very strongly as a statement ender to me, and yet at the same time, it's still visually quite close to `,`. My first impression was that the proposal had an embarrassing typo in the very first example.

My suggestion would be to reuse our normal && operator:

  guard
    x == 0 &&
    let y = optional &&
    z == 2
    else { ... }

This would obviously be a built-in `&&` separate from our existing, infix operator `&&`. (Well, unless we make `let` and `case` clauses return Bools in an `if` statement, and somehow teach the compiler that `&&` will return `false` if a binding fails.) But there is no ambiguity about the meaning of this code. It is obvious that both conditions have to succeed, and it is obvious that `z == 2` was not meant to be another optional binding. Honestly, in some ways it's more understandable than the status quo.

• Is the problem being addressed significant enough to warrant a change to Swift?

Maybe, if we have a good enough solution. I don't think this is it.

• Does this proposal fit well with the feel and direction of Swift?

I think it's kind of neutral, honestly.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Most languages I've used have `if` statements which take a simple boolean expression, so they don't face this problem.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Pretty much a glance.

···

--
Brent Royal-Gordon
Architechies

Brandon_Knope · May 27, 2016, 9:06pm

I am giving a -1 for this proposal.

While I am sure it has merit, I am finding it to be a really technical change (meaning it makes the language look more technical at the expense of some of its beauty)

First, I do not find this example very compelling:
guard
    x == 0,
    let y = optional where z == 2
    else { ... }

…in fact I did not know you could even do something like this: putting an unrelated variable in the where clause. Why not just require that variables in the where clause must have been bound from a previous statement in the conditional. This would make the where clause related to the clause that proceeds it

For example:
guard
    x == 0,
    let y = optional where y == 2 //y was just bound from an optional
    else { ... }

This I believe is more in spirit with what was intended with where clauses. To me, it should be an error to begin a where clause with a variable that does not proceed it anywhere in the conditional.

Second, I have really gotten use to not needing to use semicolons, and this proposal seems to use/require them in very common situations.

After shedding the requirement of semicolons from ObjC…now we will have to use them a lot again?

Third, the format will look like this in most people’s code:
guard x == 0; let y = optional; y == 2 else { //can the third bool condition even refer to y? Is it still in scope?
...
}
(in the above example, y == 2 is related to the optional that precedes it. Now it looks like a distinct statement)

compared to

guard x == 0, let y = someOptional where y == 2 else {
...
}

To my eyes: the old way reads more naturally and looks less heavy. I think it keeps its expressiveness and also keeps it somewhat poetic.

Also, can someone refer me to an example of this statement: "This proposal resolves this problem by retaining commas as separators within clauses (as used elsewhere in Swift) and introducing semicolons to separate distinct kinds of clauses (which aligns with the rest of the Swift language)”

I rarely see any semicolons after the removal of C loops. So if someone could put me to where this is used elsewhere in Swift, please do!

Thanks,
Brandon

···

On May 27, 2016, at 3:11 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0099 “Restructuring Condition Clauses” begins now and runs through June 3, 2016. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link:

    https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe

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

L_Mihalkovic · May 27, 2016, 7:53pm

Hello Swift community,

The review of SE-0099 “Restructuring Condition Clauses” begins now and runs through June 3, 2016. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link:

    https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?

+1

• Is the problem being addressed significant enough to warrant a change to Swift?

yes. anything to avoid series of cascading guard statements will help push people in the direction of before/after where the safety is verified before proceeding further into a function

• Does this proposal fit well with the feel and direction of Swift?

guard is an essential tool of idiomatic Swift. making it more fluid feels like it removes the right road-blocks

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

using a “;” between successive conditions lists bares a resemblance with how conditions are structured in the Golang IF statement
if err := dec.Decode(&val); err != nil {
// ERR has been bound and validated to be NOT nil

}
this is one of my favorite features of the language

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

followed the discussions and understanding the pre-existing limitations this change will lift

···

On May 27, 2016, at 9:11 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe

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

griotspeak · May 28, 2016, 7:22pm

• What is your evaluation of the proposal?
+1
• Is the problem being addressed significant enough to warrant a change to
Swift?
Yes. I have often been frustrated by needing to break up conditions to make
complex checks. I am not completely sure that this proposal addresses that
issue but it is certainly a step in the direction of resolving it.
• Does this proposal fit well with the feel and direction of Swift?
Yes
• If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?
Yes. I think that this compares well. It also helps stabilize coding style
decisions.
• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
A couple quick readings.

···

On Fri, May 27, 2016 at 1:11 PM, Joe Groff <jgroff@apple.com> wrote:

Hello Swift community,

The review of SE-0099 “Restructuring Condition Clauses” begins now and
runs through June 3, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at
the top of the message:

* Proposal link:
https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>
Reply text Other replies*

*What goes into a review?*
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to
Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe

Review Manager

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

Chris_Lattner · May 28, 2016, 10:48pm

Thanks everyone. FYI, Erica and I discussed it offlist and agreed to amend the proposal: now you can use semicolons or a newline to separate clauses of different types.

-Chris

···

On May 27, 2016, at 12:11 PM, Joe Groff <jgroff@apple.com> wrote:

Hello Swift community,

The review of SE-0099 “Restructuring Condition Clauses” begins now and runs through June 3, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

Haravikk3 · May 28, 2016, 6:28pm

• What is your evaluation of the proposal?

Uncertain. I understand the intent behind it, but personally I really like the where clause as it covers most cases where I need to mix and match, and I feel that it’s very clean, clear, reads well and encourages best practice. I definitely prefer the first of these two options:

if let foo = maybeFoo where foo > 5 { … }
if let foo = maybeFoo; foo > 5 { … }

I also get the intent behind semi-colon usage for avoiding ambiguity, but I’d prefer it to be optional for cases where I really need to use it. We could perhaps make the compiler more strict to encourage its use though, i.e- anywhere the comma becomes ambiguous visually a warning could appear suggesting a semi-colon?

• Is the problem being addressed significant enough to warrant a change to Swift?

Simplification of some of the features of conditionals would certainly be nice, and easier to maintain. I wouldn’t say it’s critical though as personally I don’t encounter many issues with the current syntax.

• Does this proposal fit well with the feel and direction of Swift?

Hard to say, I like the consistency of having the where clause in regular conditionals rather than just loops, so I’m not in favour of that change. Semi-colon use kind of fits with how they’re used for multiple statements on a line, but I prefer how commas look within conditionals.

···

On 27 May 2016, at 20:11, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

zwaldowski · May 30, 2016, 4:15pm

I have concerns. Responses inline.

Sincerely,
Zachary Waldowski
zach@waldowski.me

• What is your evaluation of the proposal?

-1. Neither semicolon-based nor newline-based conditionals strike me as
sufficiently better, and I do not feel it achieves its overall goal of
being easier to read.

The ";" did not pass my initial sniff test of readability. Though its
rationale is convincing, I found it difficult to parse a ";"-based
conditional as something being capable of short-circuiting and
binding. I personally would prefer resolving the ambiguities around
the ",", though I cannot speak to the feasibility of that relative to
the compiler.

The newline-based version gives me particular heartburn. I do not agree
with the notion that conditional lists and multi-line statements are
long-lost twins. The proposed syntax damages the context-awareness of
an element in a conditional list; conditionals must be read and
executed holistically, but, with the new syntax, an isolated line is
not clearly a part.

Consider, for example, a transposition of a few lines; regular
statements enjoy a low rate of accidental behavioral change without
comparable syntax change (because of optional bindings, guard, etc). My
current project team has a hard time resolving merge conflicts (ironic -
it causes a lot of them too). I don't have to work hard to imagine a
scenario like "goto fail;" with one of these newline-based conditionals,
which would be an unfortunate backslide for Swift.

• Is the problem being addressed significant enough to warrant a
change to Swift?

Yes. The current syntax(es) are often surprising as to what kinds of
checks, bindings, and pattern matches can be achieved in a single
conditional. If one member of a team is more fluent in the available
combinations of Swift conditionals than another, it's not uncommon
for the other member to review code and say, "Wow, are you sure you
can do that?"

• Does this proposal fit well with the feel and direction of Swift?

It is strongly in line with Swift's direction to combine many organically-
added syntax variations into a single overarching vision.

I have misgivings about a change like this coming to a head so close to
Swift 3's coming-out party.

• If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

I haven't seen the semicolon syntax before (except maybe in C-
style for loops), making it a fairly novel and surprising addition
to the language.

Both forms of the new syntax give me concerns, but the Pythonic quality
of the newline-based version does in particular.

• How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?

I read through the revised proposal in detail.

···

On Fri, May 27, 2016, at 12:11 PM, Joe Groff via swift-evolution wrote:

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

David_Ronnqvist · May 30, 2016, 7:06pm

• What is your evaluation of the proposal?

Mixed. But I think it leans towards the negative.

At first I thought it was a big improvement, but after looking at how our team currently writes guard statements, the where clause is almost always using the unwrapped value (as opposed to an arbitrary boolean condition). The way we’ve been using it makes it feels like the optional unwrapping and the where clause belongs together, and I find that the where keyword is easy to skim for at the end of the line to look for other criteria on the unwrapped value.

Also, in most of our cases (although that may be because of the current syntax) there is only one where clause and no further unwrapping after that. In such cases, I find the current syntax very readable. More so than I find the semicolon syntax.

guard let x = someOptional where x > 0
else { }

I acknowledge that the semicolon (or newline) versions are "simpler" and probably more suited for complex guard statements with many conditions and possibly also a mix of conditions that aren’t directly related to the optional unwrapping before them. However, I would not want to trade for that for what I feel is the more readable syntax in the more common cases.

Also, if I read the proposal correctly it would be possible to combine different boolean conditions using a “;”. Meaning this:

if x == 0 && y > x { }

would be the same as this:

if x == 0; y > x { }

which is more consistent in combining conditions but introduces two different ways of AND-ing two boolean conditions.
It’s currently not possible to combine boolean conditions with a comma like this, and if that remains the case with semicolons, then this isn’t an issue.

• Is the problem being addressed significant enough to warrant a change to Swift?

I'm not sure about that.

• Does this proposal fit well with the feel and direction of Swift?

Yes

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal in detail.

- David

27 maj 2016 kl. 21:11 skrev Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

···

Hello Swift community,

The review of SE-0099 “Restructuring Condition Clauses” begins now and runs through June 3, 2016. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

  Proposal link:

    https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

  Reply text

  Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe

Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

benrimmington · June 3, 2016, 10:25pm

<swift-evolution/proposals at master · apple/swift-evolution · GitHub
0099-conditionclauses.md>

+1

I think the new guard/if/while grammar is an improvement.

We have a limited number of ASCII punctuation characters,
and the semicolon is currently underused in Swift.

-- Ben

Fabian_Ehrentraud · June 6, 2016, 6:45am

• What is your evaluation of the proposal?
-1 for the current proposal, +1 for being able to mix regular boolean expressions and `let` expressions.

• Is the problem being addressed significant enough to warrant a change to Swift?
Yes, not being able to mix different clause types feels artificial in current Swift.

• Does this proposal fit well with the feel and direction of Swift?
No, semicolons don't read very Swifty.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

···

-

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
10 minutes

On 27.05.2016, at 21:11, Joe Groff via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of SE-0099 “Restructuring Condition Clauses” begins now and runs through June 3, 2016. The proposal is available here:

github.com

apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

# Restructuring Condition Clauses

* Proposal: [SE-0099](0099-conditionclauses.md)
* Authors: [Erica Sadun](https://github.com/erica), [Chris Lattner](https://github.com/lattner)
* Review Manager: [Joe Groff](https://github.com/jckarter)
* Status: **Implemented (Swift 3)**
* Decision Notes: [Rationale](#rationale)
* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/83053c5f5395987caf2ecb3830a5cd8dc6213237/proposals/0099-conditionclauses.md)

## Introduction

Swift condition clauses appear in `guard`, `if`, and `while` statements. This proposal re-architects the condition grammar to enable an arbitrary mix of Boolean expressions, `let` conditions (which test and unwrap optionals), general `case` clauses for arbitrary pattern matching, and availability tests.  It removes `where` clauses from optional binding conditions and case conditions, and eliminates gramatical ambiguity by using commas for separation between clauses instead of using them both to separate clauses and terms within each clause.  These modifications streamline Swift's syntax and alleviate the situation where many Swift developers don't know they can use arbitrary Boolean conditions after a value binding.

Swift-evolution thread:
[\[Pitch\] making where and ,	interchangeable in guard conditions](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018352.html)

## Motivation

Swift currently allows an arbitrary mix of binding, patterns, availability
tests, and Boolean assertions within a single compound condition. However, its grammar includes ambiguity that force subsequent Boolean assertions to be preceded by a `where` clause (with a special-case exception made for availability tests).

This file has been truncated. show original

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

github.com

apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

# Restructuring Condition Clauses

* Proposal: [SE-0099](0099-conditionclauses.md)
* Authors: [Erica Sadun](https://github.com/erica), [Chris Lattner](https://github.com/lattner)
* Review Manager: [Joe Groff](https://github.com/jckarter)
* Status: **Implemented (Swift 3)**
* Decision Notes: [Rationale](#rationale)
* Previous Revision: [1](https://github.com/apple/swift-evolution/blob/83053c5f5395987caf2ecb3830a5cd8dc6213237/proposals/0099-conditionclauses.md)

## Introduction

Swift condition clauses appear in `guard`, `if`, and `while` statements. This proposal re-architects the condition grammar to enable an arbitrary mix of Boolean expressions, `let` conditions (which test and unwrap optionals), general `case` clauses for arbitrary pattern matching, and availability tests.  It removes `where` clauses from optional binding conditions and case conditions, and eliminates gramatical ambiguity by using commas for separation between clauses instead of using them both to separate clauses and terms within each clause.  These modifications streamline Swift's syntax and alleviate the situation where many Swift developers don't know they can use arbitrary Boolean conditions after a value binding.

Swift-evolution thread:
[\[Pitch\] making where and ,	interchangeable in guard conditions](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018352.html)

## Motivation

Swift currently allows an arbitrary mix of binding, patterns, availability
tests, and Boolean assertions within a single compound condition. However, its grammar includes ambiguity that force subsequent Boolean assertions to be preceded by a `where` clause (with a special-case exception made for availability tests).

This file has been truncated. show original

Reply text

Other replies

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

github.com

apple/swift-evolution/blob/master/process.md

# Swift Evolution Process

Swift is a powerful and intuitive programming language that is designed to make writing and maintaining correct programs easier. Swift is growing and evolving, guided by a community-driven process referred to as the Swift evolution process. This document outlines the Swift evolution process and how a feature grows from a rough idea into something that can improve the Swift development experience for millions of programmers.

## Scope

The Swift evolution process covers all changes to the Swift language and the public interface of the Swift standard library, including new language features and APIs (no matter how small), changes to existing language features or APIs, removal of existing features, and so on. Smaller changes, such as bug fixes, optimizations, or diagnostic improvements can be contributed via the normal contribution process; see [Contributing to Swift](https://swift.org/community/#contributing).

## Goals

The Swift evolution process aims to leverage the collective ideas, insights, and experience of the Swift community to improve the Swift development experience. Its two primary goals are:

* Engage the wider Swift community in the ongoing evolution of Swift, and
* Maintain the vision and conceptual coherence of Swift.

There is a natural tension between these two goals. Open evolution processes are, by nature, chaotic. Yet, maintaining a coherent vision for something as complicated as a programming language requires some level of coordination. The Swift evolution process aims to strike a balance that best serves the Swift community as a whole.

## Participation

Everyone is welcome to propose, discuss, and review ideas to improve

This file has been truncated. show original

Thank you,

-Joe

Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

hartbit · June 6, 2016, 7:26am

• What is your evaluation of the proposal?

+1 I’ve always been annoyed by the complicated grammar of condition clauses. This proposal simplifies them and makes them easier to understand and teach.

Especially, I regret that the syntax for A && B is different than B && A when A is a boolean expression and B is an optional unwrapping clause. It breaks a nice visual symmetry:

if a, let b = b {}
if let b = b where a {}

This proposal brings back the symmetry.

• Is the problem being addressed significant enough to warrant a change to Swift?

It is.

• Does this proposal fit well with the feel and direction of Swift?

It brings more consistency, and it breaks the syntax. So it should be introduced for Swift 3.

• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I haven’t used languages which had anything else than boolean expressions in their condition clauses, but I’ve always expected the syntax of A && B to be symmetrical to B && A.

• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A long read of the original discussion and the review discussion.

···

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Joe

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

Erica_Sadun · May 27, 2016, 7:37pm

Given the whole newline groundswell that has emerged on SE, I did consider it but when I mocked up examples, it felt less readable and I suspect it would negatively affect the clarity of parsing this proposal aims to introduce.

I'd really like to see a separate newline-as-separator proposal brought forward and formally reviewed. It's garnered a few very vocal supporters but it really doesn't fall under the umbrella of this proposal. I'd like the matter to be settled one way or the other for the sake of closure.

-- Erica

···

On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

• What is your evaluation of the proposal?

+1. I believe it improves the clarity of condition clauses and as the proposal suggests, I think it will make it easier for programmers to learn and understand what is possible with them.

Did you consider allowing the semicolon to be omitted when a newline separates conditions? Something like this:

anandabits · May 27, 2016, 7:47pm

• What is your evaluation of the proposal?

+1. I believe it improves the clarity of condition clauses and as the proposal suggests, I think it will make it easier for programmers to learn and understand what is possible with them.

Did you consider allowing the semicolon to be omitted when a newline separates conditions? Something like this:

Given the whole newline groundswell that has emerged on SE, I did consider it but when I mocked up examples, it felt less readable and I suspect it would negatively affect the clarity of parsing this proposal aims to introduce.

Maybe Joe can comment on the parsing question.

What kinds of examples did you look at where you felt that way? IMO the example in the proposal reads better without the semicolons:

guard
    x == 0;
    let y = optional;
    z == 2
    else { ... }

vs

guard
    x == 0
    let y = optional
    z == 2
    else { ... }

I'd really like to see a separate newline-as-separator proposal brought forward and formally reviewed. It's garnered a few very vocal supporters but it really doesn't fall under the umbrella of this proposal. I'd like the matter to be settled one way or the other for the sake of closure.

The other discussion has been about introducing newline-as-separator for comma separated lists.

I raised the question in my review because Swift already uses newline-as-separator for semicolon separated lists (statements).

-Matthew

···

On May 27, 2016, at 2:37 PM, Erica Sadun <erica@ericasadun.com> wrote:

On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

-- Erica

Erica_Sadun · May 28, 2016, 12:00am

In theory because if/guard/when create a mini scope, this might be possible to use in this context but I'll defer to Chris to reply to the issue of whether it's a better separator. Keep in mind that the proposal doesn't update the grammar for each of the conditions so the following is possible

guard
  x == 0 && a == b && c == d &&
  let y = optional, w = optional2, v = optional 3 &&
   z == 2
else { ... }

Figuring out where to break the first line into expression and into condition (after the `d`) could be very challenging to the compiler.

-- Erica

···

On May 27, 2016, at 5:35 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

    https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

  • What is your evaluation of the proposal?

Oof.

I am not a fan of this syntax. `;` reads very strongly as a statement ender to me, and yet at the same time, it's still visually quite close to `,`. My first impression was that the proposal had an embarrassing typo in the very first example.

My suggestion would be to reuse our normal && operator:

  guard
    x == 0 &&
    let y = optional &&
    z == 2
    else { ... }

Erica_Sadun · May 28, 2016, 12:13am

Second, I have really gotten use to not needing to use semicolons, and this proposal seems to use/require them in very common situations.

After shedding the requirement of semicolons from ObjC…now we will have to use them a lot again?

Third, the format will look like this in most people’s code:
guard x == 0; let y = optional; y == 2 else { //can the third bool condition even refer to y? Is it still in scope?
...
}
(in the above example, y == 2 is related to the optional that precedes it. Now it looks like a distinct statement)

compared to

guard x == 0, let y = someOptional where y == 2 else {
...
}

To my eyes: the old way reads more naturally and looks less heavy. I think it keeps its expressiveness and also keeps it somewhat poetic.

This proposal serves the grammar, enabling it to simplify, the compiler to avoid errors, and the developer to intermingle tests more naturally, as you would in processing JSON without having to nest or sequence separate guard statements. A main goal is differentiating the commas between conditions and in binding conditions, as you ask about below

I don't think it's practical to use a second braced scope:

guard {
   condition
   condition
   condition
} else {
   leave scope
}

This would be confusing to anyone doing conditional binding for use in the top level scope; the bindings would "escape" the braces. Using semicolons establishes a balance between separating different kinds of conditions and allowing comma-delineated multiple bindings.

Current state:

* Confusing, complicated, organically grown grammar
* Inability to use independently standing Boolean assertions after the first (except for one outlier availability case)

Proposed state:

* Very simple grammar
* Developer-directed ordering of binding, availability, Boolean assertions, cases, used in the order they're consumed
* Slightly uglier

The cost for this is a separator between conditions

Also, can someone refer me to an example of this statement: "This proposal resolves this problem by retaining commas as separators within clauses (as used elsewhere in Swift) and introducing semicolons to separate distinct kinds of clauses (which aligns with the rest of the Swift language)”

guard let x = opt1, y = opt2, z = opt3; booleanAssertion else { }

I rarely see any semicolons after the removal of C loops. So if someone could put me to where this is used elsewhere in Swift, please do!

Using semicolons brings conditions in-line with how semicolons are used as separators elsewhere in the Swift grammar.

-- Erica

···

On May 27, 2016, at 3:06 PM, Brandon Knope via swift-evolution <swift-evolution@swift.org> wrote:

L_Mihalkovic · May 28, 2016, 6:14am

Golang has IMO successfully used this in their IF statement. Coming from a recent imersion into the language, it is not as distracting in real life code on a day to day basis, as it might seem to be when first seen in a spec. Considering the parallel with the swift guard, this is IMO a nice advancement.

···

On May 28, 2016, at 1:35 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

       https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md

   • What is your evaluation of the proposal?

Oof.

I am not a fan of this syntax. `;` reads very strongly as a statement ender to me, and yet at the same time, it's still visually quite close to `,`. My first impression was that the proposal had an embarrassing typo in the very first example.

My suggestion would be to reuse our normal && operator:

   guard
       x == 0 &&
       let y = optional &&
       z == 2
       else { ... }

This would obviously be a built-in `&&` separate from our existing, infix operator `&&`. (Well, unless we make `let` and `case` clauses return Bools in an `if` statement, and somehow teach the compiler that `&&` will return `false` if a binding fails.) But there is no ambiguity about the meaning of this code. It is obvious that both conditions have to succeed, and it is obvious that `z == 2` was not meant to be another optional binding. Honestly, in some ways it's more understandable than the status quo.

   • Is the problem being addressed significant enough to warrant a change to Swift?

Maybe, if we have a good enough solution. I don't think this is it.

   • Does this proposal fit well with the feel and direction of Swift?

I think it's kind of neutral, honestly.

   • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Most languages I've used have `if` statements which take a simple boolean expression, so they don't face this problem.

   • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Pretty much a glance.

--
Brent Royal-Gordon
Architechies

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

Chris_Lattner · May 28, 2016, 5:11pm

• What is your evaluation of the proposal?

+1. I believe it improves the clarity of condition clauses and as the proposal suggests, I think it will make it easier for programmers to learn and understand what is possible with them.

Did you consider allowing the semicolon to be omitted when a newline separates conditions? Something like this:

No I didn’t think about or consider it. I agree with you that this seems like it would be consistent with the rest of the language and can use the same mechanics we use for disambiguating two expressions on consecutive lines in a brace statement. It also seems like it would lead to more pretty code in general as well.

Given the whole newline groundswell that has emerged on SE, I did consider it but when I mocked up examples, it felt less readable and I suspect it would negatively affect the clarity of parsing this proposal aims to introduce.

I'd really like to see a separate newline-as-separator proposal brought forward and formally reviewed. It's garnered a few very vocal supporters but it really doesn't fall under the umbrella of this proposal. I'd like the matter to be settled one way or the other for the sake of closure.

I agree that this could be positioned as a subsequent additional proposal. I’d personally be fine with looping this into the original proposal, but I’m also happy to split it out if you'd prefer Erica,

-Chris

···

On May 27, 2016, at 12:37 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On May 27, 2016, at 1:28 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

Chris_Lattner · May 28, 2016, 5:26pm

I am not a fan of this syntax. `;` reads very strongly as a statement ender to me,

Technically speaking, Swift uses semicolon as a separator, not a line ender. We already use it to separate multiple expressions on the same line, typically when those expressions are side effecting:

print(“foo”); print(“bar”) // silly example

The proposal is consistent with this usage.

and yet at the same time, it's still visually quite close to `,`. My first impression was that the proposal had an embarrassing typo in the very first example.

Particularly if we end up with Matthew’s proposal to allow omitting the semicolon when it is at the end of the line, I think we’d end up with much nicer looking code in practice. Here are a couple of random example conditions I pulled from AlamoFire (feel free to pick some of your own):

Now:
     if let
         path = fileURL.path,
         fileSize = try NSFileManager.defaultManager().attributesOfItemAtPath(path)[NSFileSize] as? NSNumber
     {

     guard let
            path = fileURL.path
            where NSFileManager.defaultManager().fileExistsAtPath(path, isDirectory: &isDirectory) && !isDirectory else
        {

if let path = fileURL.path where NSFileManager.defaultManager().fileExistsAtPath(path) {

With SE-0099 + Matthew’s extension, this could be written more nicely as:

     if let path = fileURL.path
        let fileSize = try NSFileManager.defaultManager().attributesOfItemAtPath(path)[NSFileSize] as? NSNumber
     {

     guard let path = fileURL.path
           NSFileManager.defaultManager().fileExistsAtPath(path, isDirectory: &isDirectory)
           !isDirectory else
        {

if let path = fileURL.path; NSFileManager.defaultManager().fileExistsAtPath(path) {

To be clear, I’m not saying I prefer alamofire’s indentation style :-)

My suggestion would be to reuse our normal && operator:

  guard
    x == 0 &&
    let y = optional &&
    z == 2
    else { ... }

This would obviously be a built-in `&&` separate from our existing, infix operator `&&`.

Yes, this is technically feasible, but it has the opposite problem from the above: && is very closely associated (in terms of programmer mindspace) with boolean conditionals, and the let/case clauses are *not* boolean conditions.

-Chris

···

On May 27, 2016, at 4:35 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote: