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

[Xiaodi Wu]

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/eaa83e7d/attachment.html>