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

Brandon Knope bknope at me.com
Tue May 31 14:16:24 CDT 2016 

I could be pedantic and say that "previousInterestingFoo" now relies on the newly bound "foo" on assignment in the while loop keeping it relevant contextually. 

Ultimately, my responsibility as a user of the language is not to try to figure out the inner workings of the grammar or the compiler. It's not where my interests are or should be really.

My interests are the readability and expressiveness of using the language as I use the language. This is not a problem I have a solution for. But as a user of the language, dropping where and introducing semicolons in a lot of places will lead to much less readable code in my opinion, no matter what you say the compiler or grammar can or cannot do. 

This may seem harsh, but as a user and advocate for the users, it's hard for me to recommend a feature that makes the language less readable just to fix the grammar. Am I suppose to care about the compiler or the grammar? Or is the usability of the language more important to me?

At the end of the day it's not up to me or the other dissenters, but we can at least voice our (rather strong) opinions and that's okay. 

Compiler/grammar folks may strongly disagree with us but this is why we have community reviews: to bring together all users of all backgrounds to the discussion whether that be in compilers, grammar, teachers, etc. 

Will this push me to stop programming in Swift if approved? No. 

Will it make it a little less enjoyable for me to use? A little. 

Brandon 

> On May 31, 2016, at 2:52 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> 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/49c8fd61/attachment.html>

More information about the swift-evolution mailing list