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

[Christopher Kornher]

Apologies for going off that tangent earlier.

> On May 31, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> 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 <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
> 
> > On May 31, 2016, at 12:52 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto: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/20160601/365f0622/attachment.html>