With the implementation of your proposal, will there be anything that can be written in where clauses that cannot be written after a comma (in the context of guard statements specifically)? If not, does the where clause become entirely a stylistic flourish? On Tue, May 24, 2016 at 11:57 Erica Sadun <[email protected]> wrote:
> 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]> 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
