[swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Vladimir.S]

 > What I'm hearing is that at least some developers would like to retain
 > where clauses in case conditions and optional binding conditions but still
 > allow the more controllable logic introduced by differentiating condition
 > types with semicolons or newlines. Is that a fair summary?

I believe so. Personally I'm +1 for leaving `where` as-is and "allow the 
more controllable logic" from the proposal.

 > * Should `where` clauses be allowed where the contents of the where clause
 > have no connection to the condition that precedes it?
 > * Is there a technical way to to check for such conformance?
 > * Should the `where` clause be left unconstrained, as it currently is in
 > switch statements and for loops, etc, which is consistent with the rest of
 > the language but contrary to the spirit of safety in Swift?
 > * Should `where` clauses be re-evaluated throughout the language?

I suggest to not introduce any rules for `where` at least in this proposal. 
Probably we can discuss all related to `where` in separate proposal.


On 31.05.2016 20:57, Erica Sadun via swift-evolution wrote:
>
>> On May 31, 2016, at 11:16 AM, Xiaodi Wu <xiaodi.wu at gmail.com
>> <mailto:xiaodi.wu at gmail.com>> wrote:
>>
>> The motivating example is a compelling illustration of a problem with the
>> current grammar. I don't think anyone would disagree that `if let y = y
>> where x < z` is an abomination.
>>
>> Now, I see no principled criteria, and none have been proposed here, that
>> would be useful to restrict what can come after `where`. Moreover, I see
>> no contention with the argument that arbitrary Boolean assertions should
>> be possible after a let binding.
>>
>> Finally, it is a stated goal of the core team that there shouldn't be
>> multiple 'dialects' of Swift, and that where possible there should be one
>> general solution rather than two options.
>>
>> Given these premises, I have to conclude that *if* the motivating issue
>> is to be fixed, we must get rid of `where`.
>
>
> This proposal does affect where clauses in:
>
>   * case conditions (case pattern initializer where-clause?)
>   * optional binding conditions (optional-binding-head
>     optional-binding-continuation-list? where-clause?)
>
> This proposal does not affect where clauses in:
>
>   * for-in statements (for case? pattern in expression where-clause?
>     code-block)
>   * case item lists (case-item-list → pattern where-clause? | pattern
>     where-clause? , case-item-list)
>   * catch clauses (catch pattern? where-clause? code-block)
>   * generic parameter clause's requirement clause
>
> What I'm hearing is that at least some developers would like to retain
> where clauses in case conditions and optional binding conditions but still
> allow the more controllable logic introduced by differentiating condition
> types with semicolons or newlines. Is that a fair summary?
>
> Here is the where clause grammar:
>
> where_clause = where where_expression
> where_expression = expression
>
> I think technically, by adding the new separators, the `where` need not be
> disallowed. That leaves the following questions:
>
> * Should `where` clauses be allowed where the contents of the where clause
> have no connection to the condition that precedes it?
> * Is there a technical way to to check for such conformance?
> * Should the `where` clause be left unconstrained, as it currently is in
> switch statements and for loops, etc, which is consistent with the rest of
> the language but contrary to the spirit of safety in Swift?
> * Should `where` clauses be re-evaluated throughout the language?
>
> -- E
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>