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
