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

Tue May 31 13:52:25 CDT 2016

See, I'd wondered about that early on. But it didn't sound like this was a
restriction that could be formalized straightforwardly in the grammar.

Even if it could, it is too restrictive. Consider:

```
var previousInterestingFoo = 0

while let foo = sequence.next() where previousInterestingFoo < 42 {
// determine if foo is interesting
// ...
if interesting {
previousInterestingFoo = foo
}
}
```

If we enforce a rule like you propose, then this example above, which
arguably does "make sense contextually," would no longer be acceptable.

Switching gears to a different argument: this proposal aims (among other
things) to provide a way to make arbitrary Boolean assertions after a let
binding in situations where the use of `where` is currently required but
reads absurdly. Whatever alternative grammar is proposed for these
arbitrary Boolean assertions will, by construction, *always* be useful
regardless of the variables used in the assertion.

Thus, if we keep `where` and enforce your proposed rule, you end up with
two ways to express the same thing; `where` clauses would permit a strict
subset of assertions that can be expressed using the alternative syntax.
And, the compiler is conscripted to be an opinionated arbiter of style.
That's a huge no-go.

Or, you might say, "I don't want to support arbitrary Boolean assertions
after let bindings at all!" Well then, if we try to enforce your proposed
rule, then a user who wants to write `let y = y where x < z` would be
driven to this gem of a workaround: `let y = y where (y == y && x < z)`.

These lines of reasoning are what have compelled me to conclude that
`where` might not be salvageable.

On Tue, May 31, 2016 at 13:04 Brandon Knope <bknope at me.com> wrote:

> Except some of us have proposed only allowing unwrapped or newly bound
> variables in the where clause:
>
> if let y = y where y < z should work
>
> If let y = y where x < z should be an error because it doesn't need to be
> in a where clause and doesn't make sense contextually.
>
> I understand the rationale about why it should be removed...but I find it
> a little extreme and a little "technical" to the point that some of the
> personality of the language will be lost...all for the sake being
> "technically" correct.
>
> This may be why some of us are against the proposal.
>
> Brandon
>
>
> On May 31, 2016, at 1:16 PM, 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`.
>
>
> On Tue, May 31, 2016 at 11:53 Brandon Knope <bknope at me.com> wrote:
>
>> To be frank, I just find the proposed syntax to be more ugly and less
>> expressive.
>>
>> I just don't find the proposal compelling enough to take away one of the
>> truly "Swifty" syntaxes that I have used and loved.
>>
>> If there are other ways to keep "where" while fixing the ambiguity I
>> would rather explore that than require semicolons everywhere.
>>
>> I have a feeling that more would object but just aren't perusing the
>> mailing lists. I think we will see much more activity come WWDC
>>
>> Brandon
>>
>> On May 31, 2016, at 12:25 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> In English (and, I'm guessing, many other languages), semicolons are used
>> as a second 'tier' of separators when commas become ambiguous. I'm puzzled
>> that a proposal to bring this longstanding convention to Swift is raising
>> so many objections, even going so far as to prompt alternatives such as
>> this that break clearly useful shorthands.
>>
>> On Tue, May 31, 2016 at 10:44 David Hart via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> Yet another alternative: would it be possible to disallow commas as
>>> variable declaration separators and use them for condition clause
>>> separators again:
>>>
>>> let a = 4, b = 8 // becomes illegal and requires to separate them on two
>>> lines
>>>
>>> if a > 4, let c = foo(), let d = bar(), c != d { // now comma is not
>>> ambiguous anymore
>>> }
>>>
>>> David.
>>>
>>> On 28 May 2016, at 02:30, Erica Sadun via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>
>>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon <brent at architechies.com>
>>> wrote:
>>>
>>> guard
>>> x == 0 && a == b && c == d &&
>>> let y = optional, w = optional2, v = optional 3 &&
>>> z == 2
>>> else { ... }
>>>
>>> Figuring out where to break the first line into expression and into
>>> condition (after the `d`) could be very challenging to the compiler.
>>>
>>>
>>> I'm not sure it is. `let` and `case` are not valid in an expression, so
>>> an `&&` followed by `let` or `case` must be joining clauses. On the other
>>> side of things, Swift's `&&` doesn't ever produce an optional, so if we're
>>> parsing an expression at the top level of an if-let, an `&&` must indicate
>>> the end of the clause. An if-case *could* theoretically include an `&&`,
>>> but pattern matching against a boolean value seems like a fairly useless
>>> thing to do in a context that's specifically intended to test booleans.
>>>
>>>
>>> Let me answer in another way that speaks to my background which isn't in
>>> compiler theory: The use of && may produce cognitive overload between the
>>> use in Boolean assertions and the use in separating condition clauses.
>>>
>>> -- E
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> _______________________________________________
>> 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/20160531/a857d7b4/attachment.html>