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

[Erica Sadun]

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.

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