Apologies for going off that tangent earlier.
> On May 31, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution
> <[email protected]> wrote:
>
> 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`?
Perhaps it is better to think in terms of starting with the boolean expression
and then figure out where the case conditions and let clauses should fit-in.
Starting with the simplest form:
if <boolean expression>
add that it can be preceded by a single let clause:
if let <let list> where <boolean expression>
where <let list> the comma separated list of assignments following a let
finishing up adding cases:
if let <let list> where <boolean expression> case <case expression>
In this final form, '<boolean expression>’, 'let <let list> where’, and
case <case expression> are all optional. One has to exist, of course.
This standardizes the form in a sensible way, I think. So: a single ‘let’ and a
single ‘case” are allowed, in the position shown.
An example:
'if let a=a, b=b, where (x==3 && y=x) || (x==2 && y!-=x) {…}'
> 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
>
> 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
>
> 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
and it is equivalent to `&&`
`if let a=a; x==3; y==4`
is equivalent to
`if let a=a; x==3 && y==4`
>
> 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 <[email protected]
> <mailto:[email protected]>> wrote:
>
> > On May 31, 2016, at 12:52 PM, Xiaodi Wu <[email protected]
> > <mailto:[email protected]>> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
