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 < [email protected]> wrote: > Draft: 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-expressionfor 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
