[swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses
Brandon Knope
bknope at me.com
Tue May 31 11:52:57 CDT 2016
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/d61f7777/attachment.html>
More information about the swift-evolution
mailing list