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

[Xiaodi Wu]

On Fri, Jun 10, 2016 at 1:20 PM, Goffredo Marocchi <panajev at gmail.com>
wrote:

> If the litmus test is whether using something can go awry and can go awry
> at runtime then you are going to have to chop off a lot of parts of most
> languages. Also, some programmers do not mind not being protected from
> themselves and trade that for extra freedom... which is not a bad thing in
> and of itself
>

Again, I agree. What I'm arguing here is that it can go awry *and* doesn't
offer extra freedom as a trade-off (*nor* serves a pedagogical purpose,
*nor* is necessary to support a key and unique feature of Swift). I don't
buy the argument that the freedom worth gaining is the trivial freedom from
using `guard`. That's like saying: I don't like arrays, and I'd like
something to give me the "freedom" from using them.


> In the end the question is an old one indeed, where do you draw the line
> between safety and freedom... as corny as it sounds. There are people on
> both sides.
>

As I outlined above, I reject that there is any tradeoff here between
safety and freedom. I see no freedom gained, only safety lost. Therefore,
there doesn't need to be a defined line to come to a conclusion. It's not
even on the same playing field.

I do not want a swift compiler flag that takes my idea and gets a team of
> contractors to build it... to take it to a ridiculous extreme :).
>
> Sent from my iPhone
>
> On 10 Jun 2016, at 19:10, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Fri, Jun 10, 2016 at 12:47 PM, James Berry <jberry at rogueorbit.com>
> wrote:
>
>>
>> On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> I think this idea--if you don't like it, then you don't have to use
>> it--is indicative of a key worry here: it's inessential to the language and
>> promotes dialects wherein certain people use it and others wherein they
>> don't. This is an anti-goal.
>>
>>
>> I’m not sold on the argument that there can’t be areas of the language
>> that are inessential. Yes, we could build a language with extremely limited
>> control structures (conditional branch and goto), and they would be used by
>> 100% of the users. Beyond that, however, everything is “inessential”.
>> Adding room for elegance and expressiveness, even when perhaps initially
>> seldom used, doesn’t seem wrong: this language is still young, after all.
>> Let’s not shoot decide a feature isn’t used before we even give it a chance
>> to be recognized as a feature.
>>
>
> I do agree with the premise here. There is absolutely something to be said
> for elegance and expressiveness. Moreover, expressiveness goes hand in hand
> with facilitating correctness. We could reduce everything to goto's and
> conditional branches, but correctness suffers greatly and readability of
> the code would be abysmal--and I think I'll find agreement that it's a
> solidly grounded opinion.
>
> So "inessential" alone is not a good sole criterion--I agree. But it is
> one of several prongs here: `where` is not only inessential, I argue that
> it lacks expressiveness (in that what is enabled by it can be expressed
> equally or even more cogently with `guard`, a more general and more
> expressive syntax overall), and it detracts from rather than helps with
> writing correct code, because we hear attestations that its use has gone
> awry (and the going awry happens at runtime!). So in essence, I would be
> content with inessential but expressive solutions, but here I argue that
> `where` is neither essential nor expressive.
>
> Elegance is in the eye of the beholder, but FWIW I do not find `where`
> elegant; it irks me greatly from an aesthetic point of view just as it
> delights others. I see no point in debating personal taste, however.
>
>
>> I would argue that at least one reason the where clause is little used on
>> for-in loops in code in the field is that it’s barely documented. I don’t
>> see any reference to it, or example of it, in the Swift 2.2 language guide.
>> One has to read the grammar for the for statement in the more technical
>> Language Reference in order to find it, and even there it’s behavior is not
>> defined that I can see.
>>
>> Using or not using a feature does not create a dialect of a language.
>>
>>
>>
>> On Fri, Jun 10, 2016 at 12:10 let var go <letvargo at gmail.com> wrote:
>>
>>> Leave it in!
>>>
>>> It's a great little tool. I don't use it very often, but when I do it is
>>> because I've decided that in the context of that piece of code it does
>>> exactly what I want it to do with the maximum amount of clarity.
>>>
>>> If you don't like it, then don't use it, but I can't see how it detracts
>>> from the language at all.
>>>
>>> The *only* argument that I have heard for removing it is that some
>>> people don't immediately intuit how to use it. I didn't have any trouble
>>> with it at all. It follows one of the most basic programming patterns ever:
>>> "For all x in X, if predicate P is true, do something." The use of the
>>> keyword "where" makes perfect sense in that context, and when I read it out
>>> loud, it sounds natural: "For all x in X where P, do something." That is an
>>> elegant, succinct, and clear way of stating exactly what I want my program
>>> to do.
>>>
>>> I don't doubt that it has caused some confusion for some people, but I'm
>>> not sold that that is a good enough reason to get rid of it. It seems
>>> strange to get rid of a tool because not everyone understands how to use it
>>> immediately, without ever having to ask a single question. As long as its
>>> not a dangerous tool (and it isn't), then keep it in the workshop for those
>>> times when it comes in handy. And even if there is some initial confusion,
>>> it doesn't sound like it lasted that long. It's more like, "Does this work
>>> like X, or does this work like Y? Let's see...oh, it works like X. Ok."
>>> That's the entire learning curve...about 5 seconds of curiosity followed by
>>> the blissful feeling of resolution.
>>>
>>> On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>> > 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.
>>>>>
>>>>> Weird. My own Swift projects (not on Github :P) use “where” all the
>>>>> time with for loops. I really like it and think it reads *and* writes far
>>>>> better as well as makes for nicer one-liners. In one project, by rough
>>>>> count, I have about 20 that use “where” vs. 40 in that same project not
>>>>> using “where”.
>>>>>
>>>>> In another smaller test project, there are only 10 for loops, but even
>>>>> so one still managed to use where.
>>>>>
>>>>> Not a lot of data without looking at even more projects, I admit, but
>>>>> this seems to suggest that the usage of “where” is going to be very
>>>>> developer-dependent. Perhaps there’s some factor of prior background at
>>>>> work here? (I’ve done a lot of SQL in another life, for example.)
>>>>>
>>>>
>>>> That is worrying if true, because it suggests that it's enabling
>>>> 'dialects' of Swift, an explicit anti-goal of the language.
>>>>
>>>>
>>>>>
>>>>> I feel like “where” is a more declarative construct and that we should
>>>>> be encouraging that way of thinking in general. When using it, it feels
>>>>> like “magic” for some reason - even though there’s nothing special about
>>>>> it. It feels like I’ve made the language work *for me* a little bit rather
>>>>> than me having to contort my solution to the will of the language. This may
>>>>> be highly subjective.
>>>>>
>>>>> l8r
>>>>> Sean
>>>>>
>>>>> _______________________________________________
>>>>> 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/20160610/af5561ed/attachment.html>