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