[swift-evolution] [Pitch] Retiring `where` from for-in loops
xiaodi.wu at gmail.com
Fri Jun 10 12:59:26 CDT 2016
On Fri, Jun 10, 2016 at 12:30 PM, let var go <letvargo at gmail.com> wrote:
> I respect that anti-goal, but I think being over-rigid about limiting
> developers' choice of expression is also an anti-goal.
> To me, it is like guard statements vs. if-let statements. Some people find
> one to be more clear than the other. Often times the best choice depends on
> the context. Sometimes a guard statement can be re-written as an if-let
> statement in a way that makes the code more clear, and vice versa.
The comparison with `guard` and `if` is a little inapt. The introduction of
`guard` solved a practical daily issue with `if` that was nicknamed the
pyramid of doom, where successive `if let` statements caused code to be
severely nested in braces and nearly unreadable. Further, you must exist
the scope with `guard`; thus, its use signals an intention not possible
with `if`. If, on the other hand, you do not wish to exit the scope, you
must use `if`. So in a Venn diagram, there are independent uses for `if`
that cannot be fulfilled by `guard`, and uses for `guard` that would be
unreadable if rewritten with `if`.
> And different people will inevitably have different personal preferences -
> their own "style", if you will - and will favor one over the other. But it
> would be a mistake to force everyone into one box in order to prevent the
> fracturing of the Swift community into "dialects."
> But most importantly (and this is really the kicker for me) there are
> times when the "where" syntax provides the maximum amount of clarity in the
> context of my code, and I don't want to lose that expressive power.
This is the key and salient point here. Would you be able to share some
examples where the `where` syntax provides a clear win in clarity? That
would definitely be a huge pro, if it can be used to solve issues in
expressiveness much like `guard` allowed elimination of the pyramid of doom.
> On Fri, Jun 10, 2016 at 10:17 AM Xiaodi Wu <xiaodi.wu at gmail.com> 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.
>> 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.
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution