[swift-evolution] [Pitch] Retiring `where` from for-in loops

[Xiaodi Wu]

On Mon, Jun 13, 2016 at 8:49 AM, Brandon Knope <bknope at me.com> wrote:

>
>
> Sent from my iPad
>
> On Jun 13, 2016, at 9:36 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope <bknope at me.com> wrote:
>
>> Are you really surprised that some people don't want this taken away?
>>
>
> Nope, that's to be expected.
>
>
>> The burden should be on those that want it taken out of the language and
>> not those that want it kept. After all something is being removed and it
>> should be a delicate process.
>>
>
> Agreed. We who think it's better to take this syntax out have advanced an
> argument with several prongs. Namely, that the `where` clause serves no
> independent purpose;
>
>
> What does this mean or matter?
>

Again, these are prongs to one argument, not independent grounds for
removal. We've discussed at length what this means above.


>
> that a more general solution has already been added to the language (as
> well as another in the stdlib);
>
>
> We have sugar all over the place to make features more palatable
>

This presumes that `guard` is unpalatable. I don't buy that claim.


>
> that the `where` clause is not necessary for progressive disclosure to new
> users before they're ready for the general solution;
>
>
> I have no clue what this is suppose to mean
>

For instance, `if let ...` is sugar for `if case let ...?`, itself sugar
for `if case let .some(...)`; there have been suggestions to remove it on
that basis. However, it has been pointed out that one purpose for that
grammar is that it allows a new user to unwrap optionals without learning a
more advanced feature, namely pattern matching. Likewise `[Int]` may be
shorthand for `Array<Int>`, but it has the bonus of removing generics from
the picture, so that a user can learn one thing first (namely arrays)
before tackling a more advanced concept.

> that it is, at present, rarely used in practice;
>
>
> It was added in the official release less than a year ago and it's not
> really documented well. And I'm not convinced it's rarely used in practice
> especially when it's exactly what you want
>
>
I've endeavored to outline why it's rarely exactly what you want. Whether
you buy it or not, well, that's another matter.


> that it has no analog in other commonly used general purpose languages in
> the C family;
>
>
> Why is this a good argument for its removal?
>

Again, it's a prong of one argument, not independent grounds for removal.
It goes to discoverability and user expectations when they approach the
language. For people who switch between languages often, features that are
unique, especially unique features that serve non-unique purposes (such as
filtering an array), will be more rarely reached for than features that are
commonly found among languages.

that it is the remnant of a direction in which the core team later decided
> not to pursue;
>
> I don't know anything about this but it sure seemed at one point they
> really liked where. It had to have gone through their own rigorous review
> process to be added in the first place?
>

It was meant to be part of a larger, more elaborate push into pattern
matching, which IIUC was found internally to be not well accepted; the
larger effort was abandoned but the incipient grammar was left behind.


>
> and that, given its lack of utility, lack of use, and vestigial state,
>
>
> Another opinion. This doesn't seem like a definitive argument for its
> removal
>

This is a summation of the prongs mentioned above.

being the cause of confusion even among a small number of users (if their
> number be small) is grounds to conclude that it is harmful to the language
> and therefore ought to be removed.
>
>
> "Harmful to the language" seems a bit extreme.
>
> I would love to hear more from the core team on this but I know they are
> just too busy right now
>
> Brandon
>
>
>
>
>> Don't be surprised when the defenders say it is more readable to them.
>> That is a *sound* argument in my opinion.
>>
>
> IMO, it cannot stand on its own as a complete argument for saving a
> feature in the face of the arguments we've advanced. Couldn't you say the
> same for `++` or `for;;` loops? I'd say our case is at least as strong as
> that for `for;;` loops. By comparison, if I recall, the `for;;` loop was
> argued to be ill-fitting the rest of the language and lacking in usage, but
> it certainly had utility independent of `for...in` loops and was well
> precedented in C languages.
>
>
>>
>> Brandon
>>
>> Sent from my iPad
>>
>> On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> This is not a sound argument. If your filtering can be expressed as a
>> where clause, then you would only have to read one line into the loop to
>> see it in the form of a guard clause.
>>
>> Moreover, if what you're arguing is that you shouldn't ever have to
>> *read* inside the loop to know if a sequence is filtered, how do you
>> propose that we do that? Remove the continue keyword?
>>
>> On Mon, Jun 13, 2016 at 6:16 AM Jean-Daniel Dupas via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> -1 for the removal.
>>>
>>> When I read code, I find it far more visible that a loop is over a
>>> filter list when the filter clause is on the same line, than when the
>>> filter clause is inside the loop.
>>>
>>> Having to read the full content of the loop to determine if the list is
>>> filtered or not is not an improvement IMHO.
>>>
>>> Moreover, I find it far cleaner to use the where clause that having to
>>> remember than I have to use the lazy accessor to avoid a performance hit.
>>>
>>> Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution <
>>> swift-evolution at swift.org> a écrit :
>>>
>>> And to follow-up to myself once again, I went to my "Cool 3rd Party
>>> Swift Repos" folder and did the same search. Among the 15 repos in that
>>> folder, a joint search returned about 650 hits on for-in (again with some
>>> false positives) and not a single for-in-while use.
>>>
>>> -- E
>>>
>>>
>>> Not to undermine this fact, but I believe the fact that `where` can be
>>> used in a for loop is not widely known. I didn't know about it until about
>>> a month ago (haven't really read much docs, but most people don't either).
>>>
>>> But after I found out about it, I started using it and it IMHO improved
>>> readability of my code. Not by much, but it's the little things that make
>>> you smile, right?
>>>
>>> Many people here argument that `where` is a Swift speciality and needs
>>> to be learned by the developer - the alternative is to teach the person
>>> what's the proper alternative - that using .filter can have performance
>>> impact and that the *correct* way is to use guard within the for loop. And
>>> that's IMHO much worse than teaching a person about using `where` within a
>>> for loop.
>>>
>>> _______________________________________________
>>> 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/20160613/327ce8a6/attachment.html>