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