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

[T.J. Usiyan]

+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 <
swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> 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 <
> 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> wrote:
>
>>
>>
>> Am 01.06.2016 um 03:47 schrieb Xiaodi Wu via swift-evolution <
>> 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>
>> wrote:
>>
>>>
>>> > On May 31, 2016, at 12:52 PM, Xiaodi Wu <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
>>
>> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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
>
>
> _______________________________________________
> 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/2ed4726a/attachment.html>