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

[Xiaodi Wu]

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 <erica at ericasadun.com> 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 <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> 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
>> swift-evolution at swift.org
>> 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/ac525ec8/attachment.html>