+1 I think that it is an improvement overall and the work for consistency is appreciated.
On Sat, Jun 4, 2016 at 10:03 PM, Greg Titus via swift-evolution < [email protected]> wrote: > > I think that Jon has exactly described my view on this proposal. Thanks, > Jon. > > -1. > > -- Greg > > On Jun 4, 2016, at 12:17 AM, Jon Shier via swift-evolution < > [email protected]> wrote: > > 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 < > [email protected]> 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 <[email protected]> wrote: > >> >> >> Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution < >> [email protected]>: >> >> 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 <[email protected]> >> wrote: >> >>> >>> > On May 31, 2016, at 12:52 PM, Xiaodi Wu <[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 > > > _______________________________________________ > 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
