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

[Dany St-Amant]

> Le 31 mai 2016 à 21:47, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> Revisiting this conversation, it seems that most of the design space has been thoroughly explored. I think all suggestions presented so far boil down to these:
> 
> Q: How is an arbitrary boolean assertion introduced after `if let`?
> 
> Option 1 (present scenario)--using `where`
> Advantages: expressive when it means exactly the right thing
> Drawbacks: makes obligatory the suggestion of a semantic relationship between what comes before and after even when there is no such relationship

On some occasion the relation may be obscure: buy junk of the road where junk is cheap and my trunk is empty. And as mentioned many times can be worked around by evil coder. So the relationship of the where clause may be better left to the code reviewers.

> Option 2--using a symbol sometimes encountered in conditional statements (e.g. `&&` or comma)
> Advantages: doesn't look out of place
> Drawbacks: needs to be disambiguated from existing uses, necessitating other changes in syntax

One issue with using && which have not been discussed so far is that it may force the uses of extra parenthesis when the where clause did contain ||

How can one represent something like:

if let x = optionalX where x < 10 || x > 90 "and" y < 10 || y > 90 { }

With the removal of the where and the use of && as to be expressed as:

if let x = optionalX && ( x < 10 || x > 90 ) && ( y < 10 || y > 90 ) { }

While using a comma (and line feed) it can be

if let x = optionalX,
    x < 10 || x > 90,
    y < 10 || y > 90
{ }

This option are two different options, the && which impact condition already uses || and the use of comma which would require disallowing multiple binding within a single let. Some said it would be weird to allow:

let x = optionalX, y = optionalY

While disallowing:

if let x = optionalX, y = optionalY { }

But these are already two different syntax; one allows where clause and the other not.

One possible good thing of disallowing the multiple binding in such construct is that it make some refactoring less puzzling.

Starting with:

if let x = expensiveOptionalX(), y = expensiveOptionalY() { }

If one want to add a 'where x < 10' there is currently two choices:

if let x = expensiveOptionalX(), y = expensiveOptionalY() where x < 10 { }
if let x = expensiveOptionalX() where x < 10, let y = expensiveOptionalY() { }

For performance and proper relation the 'where' should be against the variable 'x', but this forces the addition of a new 'let' which most coder will add only after seeing the compile error and possibly after the use of some foul language.


Dany

> 
> Option 3--using a symbol never encountered in conditional statements (e.g. semicolon)
> Advantages: doesn't need to be disambiguated from any existing uses
> Drawbacks: looks out of place
> 
> For me, options 1 and 2 have permanent and objective drawbacks. By contrast, familiarity increases with time, and beauty is in the eye of the beholder.
> 
> * * *
> 
> It does occur to me that there is one more option. I don't know that I like it, but it's an option no one has put forward before: recite the opening keyword when beginning a new boolean expression:
> 
> `if let x = x where x < 3 { ... }` becomes
> `if let x = x if x < 3 { ... }`
> 
> `while let item = sequence.next() where item > 0 { ... }` becomes
> `while let item = sequence.next() while item > 0 { ... }`
> 
> etc.
> 
> 
> On Tue, May 31, 2016 at 2:00 PM, Erica Sadun <erica at ericasadun.com> wrote:
>> 
>> > On May 31, 2016, at 12:52 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>> > These lines of reasoning are what have compelled me to conclude that `where` might not be salvageable.
>> 
>> To which, I'd add: `where` suggests there's a subordinate and semantic relationship between the primary condition and the clause. There's no way as far as I know this to enforce it in the grammar and the proposal allows both clauses to be stated even without the connecting word. You could make a vague argument, I suppose, for renaming `where` to `when` but all in all, even killing `where` we benefit with better expressive capabilities and a simpler grammar.
>> 
>> -- E
> 
> _______________________________________________
> 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/20160607/6c7e7dbf/attachment.html>