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

[Erica Sadun]

> On May 31, 2016, at 11:16 AM, Xiaodi Wu <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160531/1f809a05/attachment.html>