[swift-evolution] [Pitch] making where and , interchangeable in guard conditions.

[Erica Sadun]

There is no way I could figure out how to restrict Boolean assertions to mentioned variables therefore I left where clauses entirely untouched.
I'd recommend people adopt in-house standards where Boolean assertions in where clauses should be semantically tied to the condition
clause that introduces them.

I will add this as a note.

-- E


> On May 24, 2016, at 9:29 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> Does this proposal distinguish between "where clauses [...] restricted to a Boolean assertion tied to variables connected to the binding or pattern condition" and "unrelated Boolean assertions [that] should be allowed to stand on their own"?
> 
> Or are both types of boolean assertions now permitted either following a comma or following a where clause?
> 
> On Tue, May 24, 2016 at 10:10 Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Draft: https://gist.github.com/erica/74cfee56a597c0e0026a90ee4e49f160 <https://gist.github.com/erica/74cfee56a597c0e0026a90ee4e49f160>
> 
> Simplifying condition clauses and intermingling expressions with other conditions
> 
> Proposal: TBD
> Author: Erica Sadun <https://github.com/erica>
> Status: TBD
> Review manager: TBD
>  <https://gist.github.com/erica/74cfee56a597c0e0026a90ee4e49f160#introduction>Introduction
> 
> This proposal adjust Swift grammar to enable the arbitrary mix of expressions among conditions rather than constraining them before other conditions. Under this proposal, expressions are no longer limited to where clauses after the initial list of Boolean conditions.
> 
> Swift-evolution thread: [Pitch] making where and , interchangeable in guard conditions <http://thread.gmane.org/gmane.comp.lang.swift.evolution/17926>
>  <https://gist.github.com/erica/74cfee56a597c0e0026a90ee4e49f160#motivation>Motivation
> 
> There is no technical reason to disallow arbitrary mixes of binding, patterns, availability tests, and Boolean assertions within a single compound condition clause. Swift currently enforces a grammar that limits expressions to where clauses after the first non-Boolean condition clause has been mentioned. This rule means that all standalone Boolean tests must precede binding and pattern conditions and allows for code such as:
> 
> guard 
>     x == 0,
>     let y = optional where z == 2
>  
>     else { ... }
> In this example, the Boolean z == 2 clause has no semantic relationship to the optional condition to which it's syntactically bound. Ideally, where clauses should be restricted to a Boolean assertion tied to variables connected to the binding or pattern condition. Unrelated Boolean assertions should be allowed to stand on their own
> 
> If accepted, the following code would be legal, as would similar usage in while and if statements.
> 
> guard
>     x == 0,
>     let y = optional,
>     z == 2
>     else { ... }
>  <https://gist.github.com/erica/74cfee56a597c0e0026a90ee4e49f160#detailed-design>Detailed Design
> 
> Under this proposal, condition lists are updated to accept a grammar along the following lines:
> 
> ‌condition-list → condition | expression | condition , condition-list | expression, condition-list
> This enables guard, while, repeat-while, and if to adopt grammars like:
> 
> guard condition-list else code-block
> while condition-list code-block
> if condition-list code-block (else-clause)?
> Note: A repeat-while statement does not use a condition list. Its grammar is repeat code-block while expression
> 
> This approach simplifies the current Swift grammar, which constructs condition clauses separately from condition lists and conditions. This extra work is needed to introduce an expression before condition lists and to allow an expression after availability checks:
> 
> condition-clause → expression
> condition-clause → expression , condition-list
> condition-clause → condition-list
> condition-clause → availability-condition , expression
> condition-list → condition | condition,condition-list
> condition → availability-condition | case-condition | optional-binding-condition
> Beyond this high level change, all three conditions (availability conditions, case conditions, and optional binding conditions) remain unaffected as do their associated where clause grammar. This solution changes list construction not whereclauses.
> 
>  <https://gist.github.com/erica/74cfee56a597c0e0026a90ee4e49f160#impact-on-existing-code>Impact on Existing Code
> 
> This proposal does not affect existing code.
> 
>  <https://gist.github.com/erica/74cfee56a597c0e0026a90ee4e49f160#alternatives-considered>Alternatives Considered
> 
> The "easiest" solution that free interchange of commas with where, permits construction of statements like the following:
> 
> // where-clause → (where | ,) where-expression
> for i in 0...10, i % 2 == 0 { print(i) }
> Adjusting the where clause in this way wouldn't introduce the ability to mix and match Boolean expressions, availability conditions, case conditions, and optional binding conditions in condition clauses, and is therefore discarded from consideration.
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160524/79df1d2f/attachment.html>