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

Jon Shier jon at jonshier.com
Sat Jun 4 02:17:26 CDT 2016


	The suitability of “where” as the keyword in these clauses is a completely separate issue. Frankly, it just comes down to English not having a good, single word to describe an if-and-only-if relationship. So “where" was chosen (some explanation from the original designers has been sorely missing in this thread). The fact that it doesn’t make sense in all cases of conversational English is largely irrelevant, since pretty much all English words in programming languages have that problem. 
	As for the actual proposal:

> 	• What is your evaluation of the proposal?
-1 

I don’t believe any of the proposed advantages outweigh the rather jarring change in syntax.

> 	• Is the problem being addressed significant enough to warrant a change to Swift?

No. There has been enough discussion in this thread to convince me that the issues with “where” are vastly overwrought and “where” is actually quite useful as a condition for binding variables. Some improvement may be possible here, especially with the error messages generated, but I think the current syntax is quite good, from a user’s perspective.

> 	• Does this proposal fit well with the feel and direction of Swift?

It feels like a regression in style. Introducing semicolons or newlines as important conditional separators feels like a throwback to C in many ways. Eliminating “where” also feels like the elimination of a unique and useful bit of Swift styling.

> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Swift is unique in this regard among the languages I’ve used, to its benefit.

> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read multiple drafts of the proposal and the entire discussion thread.

> On Jun 1, 2016, at 1:35 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> It is of course true that all parts of a conditional statement have something in common with each other, namely that they are part of the same conditional statement.
> 
> A problem definitely exists with the current syntax, which is that the de minimis semantic relationship you are showing is not the relationship implied by the meaning of the word "where."
> 
> It is acceptable to say, "I will buy all the apples that are on sale, where the sale is 5% off or better." It is not acceptable to say, "I will buy all the apples that are on sale, where my bike is large," even if it is true that you would only buy all the apples if you had a large bike to transport them home.
> 
> On Wed, Jun 1, 2016 at 11:50 Thorsten Seitz <tseitz42 at icloud.com <mailto:tseitz42 at icloud.com>> wrote:
> 
> 
> Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
> 
>> 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
> 
> Haravikk already demonstrated that a semantic relationship always exists in the sense of "bind this variable for all caes where the following condition holds".
> 
> So, the perceived problem with the `where` clause does not exist.
> 
> -Thorsten 
> 
> 
>> 
>> 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
>> 
>> 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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160604/77270930/attachment.html>


More information about the swift-evolution mailing list