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

xwu · June 13, 2016, 12:16am

* The word "where" does not consistently imply `break` or `continue`.
In current Swift, `where` implies `break` in the context of a `while` loop
and `continue` in the context of a `for` loop. Some users intuitively guess
the correct meaning in each context, while others guess the wrong meaning.
Therefore, the only way to learn for sure what `where` means in any context
is to read the rulebook. That, by definition, means that this is
unintuitive.

This is an argument for renaming the where keyword on for loops to be
more clear, or to somehow integrate continue/break to be more explicit
about what the developer intends for it to do.

Sure: I conclude that the keyword should be *either* removed *or*
reformed; both outcomes could address the issue.

This is my stance as well and I reserve the right to flit between both
choices until we've fully talked it through.

One more data point.

In the standard library there are just under 950 uses of "for in
loops". There are 3 uses of "for in while" :

How many of the 950 "for in loops" use a guard with continue? Only
these can be compard with the "for in where loops".

That is a different argument, I think, from the one Erica is making. The
data you're asking about would answer the question, "How often do stdlib
authors prefer `guard` over `where`?" That is an interesting question,
certainly.

It is the relevant question to ask when deciding whether `where` should
be better replaced by `guard`. And it should be qualified by asking whether
the respective author did know about `where`. I wouldn't want a language to
be designed by looking at usage examples of inexperienced users...

Here, I disagree with you vehemently. We should absolutely take into
consideration how inexperienced users work with the language. A language
that ignores the struggles and pain points of those who are less
experienced is one that will quickly find itself lacking in users.

You don't want to tell me in earnest that discovering and understanding
`where` in for loops are stumbling blocks for beginners in a language
containing generics, associated types, existentials, value vs. reference
types etc.?

I do. I challenge you to find an introductory text that teaches generics,
associated types, existentials, or even value vs. reference types before it
introduces `for` loops or `if` (and `guard`).

My point was that someone who endeavors to learn a language like Swift
which does include all these things, will not falter when he stumbles upon
`where` in a `for` loop.

I'm not sure how you can come to this conclusion that a new user *will not*
falter over this concept or that simply because a language includes more
difficult concepts. I have seen bright students struggle with `i = i + 1`
when learning to code in languages with advanced concepts. (See if you can
guess what is confusing about `i = i + 1`.) Know that if a user cannot
master loops, then he or she cannot write very much of consequence in a
language at all. But a user who does not understand generics, associated
types, existentials, or value vs. reference types can still very well find
some good use for Swift in the meantime.

He might be surprised for a moment (when coming from other languages but

···

On Sun, Jun 12, 2016 at 8:28 AM, Thorsten Seitz <tseitz42@icloud.com> wrote:

Am 12.06.2016 um 00:16 schrieb Xiaodi Wu <xiaodi.wu@gmail.com>:
On Sat, Jun 11, 2016 at 5:07 PM, Thorsten Seitz <tseitz42@icloud.com> > wrote:

Am 11.06.2016 um 23:52 schrieb Xiaodi Wu <xiaodi.wu@gmail.com>:
On Sat, Jun 11, 2016 at 3:31 PM, Thorsten Seitz <tseitz42@icloud.com> >> wrote:

Am 11.06.2016 um 21:57 schrieb Xiaodi Wu <xiaodi.wu@gmail.com>:
On Sat, Jun 11, 2016 at 2:50 PM, Thorsten Seitz <tseitz42@icloud.com> >>> wrote:

Am 10.06.2016 um 17:22 schrieb Erica Sadun via swift-evolution < >>>> swift-evolution@swift.org>:
On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution < >>>> swift-evolution@swift.org> wrote:
On Fri, Jun 10, 2016 at 7:18 AM, Haravikk <swift-evolution@haravikk.me> >>>> wrote:

probably not when Swift is his first language, nor when he already knows
languages like C# or SQL) but not more.

-Thorsten

-Thorsten

I think Erica's point is that what Vladimir earlier called the "simple,
common" case may be simple but isn't actually common. I did a quick GitHub
search earlier today (and the tools aren't there, afaik, for an accurate
regexp search), but what I noticed on a random, not-statistically-sound
sampling was that uses of `continue` and `break`, when they do occur inside
a for loop (which isn't always), actually tend to happen after some work
has been done at the top of the loop. These wouldn't be replaceable by a
`where` clause. Moreover, I noticed an appreciable share of `return` and
`fatalError()` calls from inside the loop, which surprised me; I had
assumed I'd find mostly `break` or `continue`, but even when I did find
those it was as likely as not to be accompanied by logging. These again
preclude refactoring into `where`.

Logging hints at logic used for filtering out data errors. That's a good
usage for `guard` as opposed to `where`. The latter is about logic, not
about error handling.

-Thorsten

xwu · June 13, 2016, 2:05pm

if-continue. But I gladly took upon for-in-where as soon as I found out
about it since it's more expressive and simply is less typing.

I don't think we use the term 'expressive' in the same way. I understand it
to mean that permitting the expression of more things. But of course,
`where` does only a subset of `guard...continue` or `if...continue`; thus,
less expressive.

···

On Mon, Jun 13, 2016 at 8:58 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:

On Jun 13, 2016, at 2:24 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

What did you use before `where` existed?

On Mon, Jun 13, 2016 at 1:29 AM Charlie Monroe via swift-evolution < > swift-evolution@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.

-- 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

BigZaphod · June 13, 2016, 2:28pm

I’m just (probably obtusely) suggesting that there are different levels and styles of expression and that the existence of one does not render other styles invalid.

In relation to the “where” debate, the fact that you can express everything with “guard” or “if” as you can with “where” is not, in my mind, a strong argument against “where” because it ignores other more intangible aspects that are going to be a lot harder to quantify since they depend on the context of the problem, the surrounding code, the mindset of the writer, and the assumed mindset of the reader.

I don’t dispute that we *could* live without “where” - that is not the point. We could also live without classes or generics or any of a variety of other features - but why should we when we don’t have to?

l8r
Sean

···

On Jun 13, 2016, at 9:19 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

How do you mean? I don't follow.
On Mon, Jun 13, 2016 at 09:11 Sean Heber <sean@fifthace.com> wrote:
> On Jun 13, 2016, at 9:05 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
>
> On Mon, Jun 13, 2016 at 8:58 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
> if-continue. But I gladly took upon for-in-where as soon as I found out about it since it's more expressive and simply is less typing.
>
> I don't think we use the term 'expressive' in the same way. I understand it to mean that permitting the expression of more things. But of course, `where` does only a subset of `guard...continue` or `if...continue`; thus, less expressive.

The fact that you could simply use the words “I am happy” to express the concept of being happy does not mean that writing a complex poem that also conveys happiness should therefore be prohibited.

l8r
Sean

xwu · June 13, 2016, 2:44pm

IMO `for-in` is a special kind of loop to manipulate(iterate) a
collection, and was introduced because we so *often* needs to iterate
collections that we need a *sugar* for this (you can do all the same with
`while` loop).

Sequences, not just collections.

It's rather tricky to write a `while` loop *correctly* to do the same thing
as a `for` loop, and it exposes the concept of the underlying iterator,
which is a more advanced concept. This is why the `for...in` loop hold its
own weight as sugar. By contrast, `while` does not, because it is trivial
to write an `if` or `guard` statement correctly, and mastering the concept
of a conditional statement is a prerequisite for mastering loops. For these
reasons, it's not apt to compare `while` clauses with `for...in` loops.

*Filtering* is another important operation we often need during the
iteration of collection.

I think the evidence has shown that it's actually not very often that you
need to do so.

This is why many of us want to keep `where` for `for-in` loop. Yes, as
sugar, because it really simplifies our every day coding(processing of
collections) and makes the code more readable(IMO) and understandable(IMO).

FWIW, IMO, it's less readable and less understandable. But there's no point
in going back and forth on this.

Personally I don't insist on `where` keyword, probably we can find another
word, so it will not be mixed with `where` in other places of the language.

Why not `filter` instead of `where` ?

for item in collection filter item < 10 {..}

we have .filter for collections, it is clear what it means, `filter` in
`for-in` mimics the same behavior, etc

I'd even suggest to make `for-in` loop more powerful with adding suggested
'while' but as under another name. So, `for-in` will be a powerful
construct to iterate, filter and break processing of collections - the only
one purpose why we need `for-in` at all.

We already have keywords for breaking and for prematurely terminating from
a loop. They're called `break` and `continue`, and they work inside every
loop.

···

On Mon, Jun 13, 2016 at 9:27 AM, Vladimir.S <svabox@gmail.com> wrote:

for item in collection until item > 100 {..}
or
for item in collection break item > 100 {..}
or
for item in collection breakif item > 100 {..}
or
for item in collection limit item > 100 {..}
or
for item in collection stop item > 100 {..}
or other keyword.

On 13.06.2016 16:36, Xiaodi Wu via swift-evolution wrote:

On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope <bknope@me.com >> <mailto:bknope@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; that a more general solution has already been added
to
the language (as well as another in the stdlib); that the `where` clause
is
not necessary for progressive disclosure to new users before they're ready
for the general solution; that it is, at present, rarely used in practice;
that it has no analog in other commonly used general purpose languages in
the C family; that it is the remnant of a direction in which the core team
later decided not to pursue; and that, given its lack of utility, lack of
use, and vestigial state, 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.

    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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution

        _______________________________________________
        swift-evolution mailing list
        swift-evolution@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution

        _______________________________________________
        swift-evolution mailing list
        swift-evolution@swift.org <mailto:swift-evolution@swift.org>
        https://lists.swift.org/mailman/listinfo/swift-evolution

    _______________________________________________
    swift-evolution mailing list
    swift-evolution@swift.org <mailto:swift-evolution@swift.org>
    https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

BigZaphod · June 13, 2016, 3:22pm

Yes, true, there are certainly two meanings in play here - the technical domain specific concept, and the more casual definition. I think the concern of myself (and some others) is that the technical definition, perhaps somewhat ironically, is not expressive enough to capture all of the facets of expression that matter to all of us! I think this particular discussion is taking place at the intersection of technology and liberal arts.

l8r
Sean

···

On Jun 13, 2016, at 10:16 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Mon, Jun 13, 2016 at 9:54 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:

On Jun 13, 2016, at 4:46 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Mon, Jun 13, 2016 at 9:28 AM, Sean Heber <sean@fifthace.com> wrote:
I’m just (probably obtusely) suggesting that there are different levels and styles of expression and that the existence of one does not render other styles invalid.

In relation to the “where” debate, the fact that you can express everything with “guard” or “if” as you can with “where” is not, in my mind, a strong argument against “where” because it ignores other more intangible aspects that are going to be a lot harder to quantify since they depend on the context of the problem, the surrounding code, the mindset of the writer, and the assumed mindset of the reader.

I don’t dispute that we *could* live without “where” - that is not the point. We could also live without classes or generics or any of a variety of other features - but why should we when we don’t have to?

I'm not sure where this comes in. I was clarifying what I mean when I call a language construct 'expressive.' As I understand the term, `where` is not expressive, whereas classes and generics are expressive.

Perhaps this is due to English not being my first language, but I go by the dictionary definition of expressive:

expressive (adjective) - effectively conveying thought or feeling.

And I believe that for-in-where is expressing the condition more effectively (and efficiently) than adding if/guard-continue into the actual code block.

That's fine for English, but I just mean that in a language design context I've always understood the word to encompass the *breadth* of thoughts that can be expressed. In that sense, `where` might express one thing economically, but it cannot express very many things at all, no matter how much text you write in a `where` clause.

xwu · June 13, 2016, 12:28pm

I think this discussion has made it pretty plain that what is claimed to be
'so useful' is barely ever used. Moreover, it provides no independent uses.
The point of these pitches is to sound out arguments, not, as far as I was
aware, to take a vote.

···

On Mon, Jun 13, 2016 at 1:54 AM Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:

--1

I think it would be a waste of the community's time to do a formal review
when only two people are in favor of this removal.

'for in where' is so useful especially since we don't have for;;; loops
anymore. I'd say leave this alone; the majority doesn't want this changed.

On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution < > swift-evolution@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.

On Fri, Jun 10, 2016 at 12:10 let var go <letvargo@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@swift.org> wrote:

On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

L_Mihalkovic · June 13, 2016, 12:30pm

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.

See the benchmarks me and Erica have posted here a few days back - even with the lazy accessor, if you decided to use filter(_:), you lost 10+% of performance. Correct way to do this without `where` and without performance penalization is to use guard within the for-in loop.

10% on a microbenchmark repeater 4000000 times is hardly a justification for going on way or the other.

···

On Jun 13, 2016, at 1:23 PM, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Charlie_Monroe1 · June 13, 2016, 2:54pm

I’m just (probably obtusely) suggesting that there are different levels and styles of expression and that the existence of one does not render other styles invalid.

In relation to the “where” debate, the fact that you can express everything with “guard” or “if” as you can with “where” is not, in my mind, a strong argument against “where” because it ignores other more intangible aspects that are going to be a lot harder to quantify since they depend on the context of the problem, the surrounding code, the mindset of the writer, and the assumed mindset of the reader.

I don’t dispute that we *could* live without “where” - that is not the point. We could also live without classes or generics or any of a variety of other features - but why should we when we don’t have to?

I'm not sure where this comes in. I was clarifying what I mean when I call a language construct 'expressive.' As I understand the term, `where` is not expressive, whereas classes and generics are expressive.

Perhaps this is due to English not being my first language, but I go by the dictionary definition of expressive:

expressive (adjective) - effectively conveying thought or feeling.

And I believe that for-in-where is expressing the condition more effectively (and efficiently) than adding if/guard-continue into the actual code block.

···

On Jun 13, 2016, at 4:46 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Mon, Jun 13, 2016 at 9:28 AM, Sean Heber <sean@fifthace.com <mailto:sean@fifthace.com>> wrote:

l8r
Sean

> On Jun 13, 2016, at 9:19 AM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
>
> How do you mean? I don't follow.
> On Mon, Jun 13, 2016 at 09:11 Sean Heber <sean@fifthace.com <mailto:sean@fifthace.com>> wrote:
> > On Jun 13, 2016, at 9:05 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >
> > On Mon, Jun 13, 2016 at 8:58 AM, Charlie Monroe <charlie@charliemonroe.net <mailto:charlie@charliemonroe.net>> wrote:
> > if-continue. But I gladly took upon for-in-where as soon as I found out about it since it's more expressive and simply is less typing.
> >
> > I don't think we use the term 'expressive' in the same way. I understand it to mean that permitting the expression of more things. But of course, `where` does only a subset of `guard...continue` or `if...continue`; thus, less expressive.
>
> The fact that you could simply use the words “I am happy” to express the concept of being happy does not mean that writing a complex poem that also conveys happiness should therefore be prohibited.
>
> l8r
> Sean
>

let_var_go · June 13, 2016, 5:46pm

That would be interesting...I assume that 'while' or 'until' would cause
early exit from the loop, and 'unless' would be the logical inverse of
'where'.

I'd have to think about it some more, but my instinct is that I would be in
favor of adding 'unless' as the logical inverse of 'where' (exclude items
based on the predicate, instead of include items based on the predicate). I
wouldn't add 'while' or 'until', because we already have conditional loops
like the 'while' loop to serve that need.

···

On Mon, Jun 13, 2016 at 8:26 AM Erica Sadun <erica@ericasadun.com> wrote:

> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I am 100% with Charlie on this. Expressiveness has to do with the
*effectiveness* of conveying a thought or a feeling.
>
> Keep "where". It is expressive. It conveys a specific idea effectively
and concisely.

For those of you in favor of retaining `where`, how do you feel about
adding `while`, `until`, `unless`, etc?

-- E

L_Mihalkovic · June 13, 2016, 3:59pm

Regards
LM
(From mobile)

I’m just (probably obtusely) suggesting that there are different levels and styles of expression and that the existence of one does not render other styles invalid.

In relation to the “where” debate, the fact that you can express everything with “guard” or “if” as you can with “where” is not, in my mind, a strong argument against “where” because it ignores other more intangible aspects that are going to be a lot harder to quantify since they depend on the context of the problem, the surrounding code, the mindset of the writer, and the assumed mindset of the reader.

I don’t dispute that we *could* live without “where” - that is not the point. We could also live without classes or generics or any of a variety of other features - but why should we when we don’t have to?

The corollary question every parent has to deal with is to learn to make a sacrifice now for a better outcome tomorrow. Maybe this is another way to look at this question?

···

On Jun 13, 2016, at 5:22 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 13, 2016, at 10:16 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Mon, Jun 13, 2016 at 9:54 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:

On Jun 13, 2016, at 4:46 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Mon, Jun 13, 2016 at 9:28 AM, Sean Heber <sean@fifthace.com> wrote:

I'm not sure where this comes in. I was clarifying what I mean when I call a language construct 'expressive.' As I understand the term, `where` is not expressive, whereas classes and generics are expressive.

Perhaps this is due to English not being my first language, but I go by the dictionary definition of expressive:

expressive (adjective) - effectively conveying thought or feeling.

And I believe that for-in-where is expressing the condition more effectively (and efficiently) than adding if/guard-continue into the actual code block.

That's fine for English, but I just mean that in a language design context I've always understood the word to encompass the *breadth* of thoughts that can be expressed. In that sense, `where` might express one thing economically, but it cannot express very many things at all, no matter how much text you write in a `where` clause.

Yes, true, there are certainly two meanings in play here - the technical domain specific concept, and the more casual definition. I think the concern of myself (and some others) is that the technical definition, perhaps somewhat ironically, is not expressive enough to capture all of the facets of expression that matter to all of us! I think this particular discussion is taking place at the intersection of technology and liberal arts.

l8r
Sean

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

xwu · June 10, 2016, 6:59pm

I think sometimes the community in this mailing list loses sight on the
fact that coding is a creative endeavour much similar to architectural
design or painting. There may be math and well researched and structured
ideas in place, but it requires creativity too.

Architects are constrained to craft buildings that will stand in the face
of gravity, and even painters don't have pigments for every color visible
to the human eye. There's a wonderful novel, _Gadsby_, written without the
letter 'e'; I haven't read it but I understand it's truly an
accomplishment. This is not so drastic here. In this case, the apt analogy
would be that we find the letter 'a with circle on top' to be posing some
pesky problems; do you think you could write a novel in English without
using 'a with circle on top'? I wager that your creativity will not suffer
(unless your novel describes a trip to IKEA, in which case I'm sorry).

···

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

Trying to force a strict one size fits all The One True standard usually
ends up fragmenting the standard further, by adding yet another take on
what is the most orthodox implementation and who are the heretics...

I do not think dismissing the idea of having more than one way of skinning
the proverbial cat as an anti-goal is doing a good service to the community
or the language as it completely disregards context, people differing idea
of the subjective best coding style and patterns (which pattern do I use?
Which algorithm do I use to sort this data set with? A good engineer will
give you a direct and concise answer, but a better one will say "it
depends... What's the context? What is the problem I need to solve, what
are the constraints and the data set I am working on?").

The way some users seem to want Swift to follow sounds like protecting
users from mistakes by sometimes removing the ability which could lead to
mistakes in the first place, but that removes all the good things you could
do if you were to trust developers with the extra responsibility.

Sent from my iPhone

On 10 Jun 2016, at 18:30, let var go via swift-evolution < > swift-evolution@swift.org> 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. 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.

On Fri, Jun 10, 2016 at 10:17 AM Xiaodi Wu <xiaodi.wu@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@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@swift.org> wrote:

On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Haravikk3 · June 11, 2016, 11:42am

I had quite a visceral reaction to the example given at one point:

for number in fibonacci where number % 2 == 0 while number < 4_000_000 {...}

This, IMO, is long enough to cause a heart attack.

This is not what’s being discussed though, that’s a separate feature request and I’ve already pointed out that I’m not that comfortable with allowing both where and while on the same line. That said, it’s worth remembering that syntax highlighting doesn’t always carry into the mailing list; in Xcode the colouration of “where” makes it a pretty significant separator between the loop and the where clause, which a “while” clause would presumably do too.

Although it’s not IMO that bad of an example (though I’m not sure I’d actually write something like that personally), I feel it’s worth pointing out that when using the guard alternatives there is absolutely nothing (besides common decency) stopping me from writing the following if I want to:

for number in fibonacci { guard number % 2 == 0 else { continue }; guard number < 4_000_000 else { break }; … }

Compared to that the for in where while variant is very elegant.

The appeal of where clauses to me is that they are a neat way to handle simple, common cases. In my own code the cases where I’d like to see a “while” variant would not be used in combination with where, in fact I can’t currently find any instance in my code where I have both a guard continue and a guard break that could be rolled into a single where while condition (I have maybe three loops that have both of these, but when I do they’re not both right at the start). That said, this is not an argument for removing where, it’s an argument for refining the proposal for a “while” variant, e.g- allow only one of these per loop (which also solves any confusion around the order they are evaluated in).

Regarding some of the numbers that have come up about for in vs for in where loops (in my own code I’m close to maybe of 20% of my for in loops using it), it’s important to recognise that the use of the where clause isn’t well advertised. When I started out with Swift I only knew that it could be used on cases in a switch statement, and later that it was used with complicated generics. It wasn’t until I joined the mailing list that I found out it could be used with conditional bindings and loops, but when I did I started using it almost immediately.

Since it is so obscure, I think it'd be fair to say that the feature is not fundamental to Swift's "character" or "style." In fact, I understand that it was added only later. I could buy the argument that, if advertised widely, people would find ways to use it more widely and perhaps even generally correctly.

The latter is what I believe; if I’d known about it sooner I would have used it sooner, but the Swift introduction I followed only seemed to use it on case statements. I found out about the other uses later for generics when I ran into the limitations of very basic type-only generics, and later still for conditional binding (at which point I tried it on while and for loops too).

The same is true of pattern matching btw; I didn’t learn about that until I joined the mailing list either, but I wouldn’t want rid of that feature either as now that I’m aware of it I find it very useful. Given that the two features are kind of linked since “where" was apparently being introduced with a view towards more powerful pattern matching, it’d be interesting to find out what that more powerful pattern matching was going to look like.

Whether either feature became vestigial or not in terms of their intended design, both are useful constructs that I think just need to be championed more.

···

On 10 Jun 2016, at 21:53, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

xwu · June 11, 2016, 10:11pm

-1

* Swift is explicitly a C-family language. In most or all other C-family
languages, for loop statements allow specification of conditions for
exiting the loop but not for filtering. Therefore, Swift's use of `where`
is unprecedented and needs to be learned anew by every user of Swift.

When was this decided? I distinctly remember some bloke under Craig
Federighi’s hair saying that it was time to “move beyond” C and essentially
ditch legacy conventions which no longer make sense.

I think you misunderstood my argument here. I don't mean that we should
yoke ourselves to C conventions, and we should absolutely ditch C
convention when it doesn't make sense. The big-picture argument here is
that `where` doesn't pass the bar of correcting a C convention that no
longer makes sense.

FWIW, on the topic of syntax choices, here is what Chris Lattner had to
say on this list:

Kevin got it exa*c*tly right, but I’d expand that last bit a bit to:

“… pi*c*king the one that is most familiar to programmers in the
extended *C* *family* is a good idea.["]
The extended *C* *family* of language (whi*c*h in*c*ludes *C*, *C*++,
Obj*C*, but also *C*#, Java, Javas*c*ript, and more) is
an extremely popular and widely used set of languages that have a lot of
surfa*c*e-level similarity. I
don’t *c*laim to know the design rationale of all of these languages,
but I surmise that this is not an
a*c**c*ident: programmers move around and work in different languages,
and this allows a non-expert in the
language to understand what is going on. While there are things about
*C* that are really unfortunate IMO
(e.g. the de*c*larator/de*c*laration spe*c*ifier part of the grammar)
there is a lot of goodness in the basi
*c*operator set, fo*c*us on dot syntax, and more.
I do agree that there are some benefits to dit*c*hing bra*c*es and
relying on indentation instead, but there are
also downsides. Deviating from the *C* *family* in this respe*c*t would
have to provide **overwhelmingly** large
advantages for us to take su*c*h a plunge, and they simply don’t exist.

As I understand it, Swift is a new language with new conventions. It is
desirable to align as many of those as possible with existing conventions
so as to be easily learned, but if you limit Swift to other languages
conventions you deny it any identity. Did Python ask anybody’s opinion
before dropping curly-braces? Did people learn whatever Perl is supposed to
be? Look at C’s hieroglyphic for loops!

I don't think we disagree here.

Realistically, “for … in … while” is not going to cause incredible
confusion. Removing it would cause a lot of frustration. You can’t on the
one hand say our users are comfortable with the axioms of C’s hieroglyphic
loops, and on the other hand say “for x in y while" is confusing.

Again, as I said, once you've mastered something, by definition you find
it not confusing. Why should we doom x% of new users to writing a loop
incorrectly at least once when we don't have to?

Ah, but if you’re not “doomed” to failing once, how will you ever master
anything? Nobody knew how to write a C for-loop until someone showed them
(and even then…). Nobody is going to just open a REPL and start writing
code, with zero prior understanding of what Swift syntax looks like.

The thought here is along the lines of what Chris said, quoted above, and
repeated here: "The extended C family of language [...] is an extremely
popular and widely used set[;] programmers move around and work in
different languages, and [aligning to expectations arising from other C
family languages] allows a non-expert in the language to understand what is
going on." By contrast, the `where` clause violates that expectation and I
do not see "overwhelmingly large advantages" for doing so.

What about C#'s `where` then? As C# is a member of the C family languages
`where` is not violating expectations!

Where is not exactly a part of c# it belongs to linq

And that is not a part of C#??

SQL is a domain-specific language, and LINQ is an internal domain-specific
language with a language extension for C#. Neither is a general purpose
language.

I don't see how that is relevant especially given the prominence and reach
of SQL (which is turing complete, btw ;-)

It is relevant because the design of every language has to contend with
trade-offs, and the trade-offs that make `where` a powerful and intuitive
keyword in the context of a query language are different from the tradeoffs
we must contend with in a general purpose language. HTML+CSS has also been
proved Turing-complete; it is irrelevant to the question of whether the
idioms of HTML+CSS are appropriate in a general purpose language.

Your example actually goes to one of Laurent's points. Should the Swift
core team or an enterprising community member propose a set of similarly
powerful tools, along with a set of language extensions that add syntactic
sugar for them, I (and I think Laurent, if I understand him correctly)
would absolutely be in favor of such an addition. But as it is, `where` is
an odd duckling. Just as you say, it looks like a component of a query
language, but it does no such thing. In a for loop, it does some filtering,
but until recently it functioned like a comma in `while` loops. Look at
those other keywords which make this sugar possible in C#: in your example,
`from` and `select`. We don't have any of that intrastructure in Swift.

We can simply extend the for-in-where loop for that like Scala does. No
need to add new syntax if an existing one can simply be generalized.

If you want to propose adopting Scala's `if`, you are free to start a
discussion on that topic. Note how Scala also avoids use of the word
`where`.

···

On Sat, Jun 11, 2016 at 5:03 PM, Thorsten Seitz <tseitz42@icloud.com> wrote:

Am 11.06.2016 um 23:45 schrieb Xiaodi Wu <xiaodi.wu@gmail.com>:
On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz <tseitz42@icloud.com> > wrote:

Am 11.06.2016 um 22:29 schrieb L. Mihalkovic < >> laurent.mihalkovic@gmail.com>:
On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution < >> swift-evolution@swift.org> wrote:
Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org>:
On Fri, Jun 10, 2016 at 6:10 AM, Karl <razielim@gmail.com> wrote:

-Thorsten

The following is an example from MSDN with `where` clearly beaing a
keyword:

*var* numQuery =
            *from* num *in* numbers
            *where* (num % 2) == 0
            *select* num;

-Thorsten

Brandon_Knope · June 12, 2016, 1:11pm

Well now you have me intrigued. I must read more about Linq now

Brandon

···

Sent from my iPad

On Jun 12, 2016, at 6:02 AM, L Mihalkovic via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 11, 2016, at 11:45 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz <tseitz42@icloud.com> wrote:

Am 11.06.2016 um 22:29 schrieb L. Mihalkovic <laurent.mihalkovic@gmail.com>:

On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution <swift-evolution@swift.org>:

On Fri, Jun 10, 2016 at 6:10 AM, Karl <razielim@gmail.com> wrote:
-1

* Swift is explicitly a C-family language. In most or all other C-family languages, for loop statements allow specification of conditions for exiting the loop but not for filtering. Therefore, Swift's use of `where` is unprecedented and needs to be learned anew by every user of Swift.

When was this decided? I distinctly remember some bloke under Craig Federighi’s hair saying that it was time to “move beyond” C and essentially ditch legacy conventions which no longer make sense.

I think you misunderstood my argument here. I don't mean that we should yoke ourselves to C conventions, and we should absolutely ditch C convention when it doesn't make sense. The big-picture argument here is that `where` doesn't pass the bar of correcting a C convention that no longer makes sense.

FWIW, on the topic of syntax choices, here is what Chris Lattner had to say on this list:

Kevin got it exactly right, but I’d expand that last bit a bit to:
“… picking the one that is most familiar to programmers in the extended C family is a good idea.["]
The extended C family of language (which includes C, C++, ObjC, but also C#, Java, Javascript, and more) is
an extremely popular and widely used set of languages that have a lot of surface-level similarity. I
don’t claim to know the design rationale of all of these languages, but I surmise that this is not an
accident: programmers move around and work in different languages, and this allows a non-expert in the
language to understand what is going on. While there are things about C that are really unfortunate IMO
(e.g. the declarator/declaration specifier part of the grammar) there is a lot of goodness in the basic
operator set, focus on dot syntax, and more.
I do agree that there are some benefits to ditching braces and relying on indentation instead, but there are
also downsides. Deviating from the C family in this respect would have to provide *overwhelmingly* large
advantages for us to take such a plunge, and they simply don’t exist.

As I understand it, Swift is a new language with new conventions. It is desirable to align as many of those as possible with existing conventions so as to be easily learned, but if you limit Swift to other languages conventions you deny it any identity. Did Python ask anybody’s opinion before dropping curly-braces? Did people learn whatever Perl is supposed to be? Look at C’s hieroglyphic for loops!

I don't think we disagree here.

Realistically, “for … in … while” is not going to cause incredible confusion. Removing it would cause a lot of frustration. You can’t on the one hand say our users are comfortable with the axioms of C’s hieroglyphic loops, and on the other hand say “for x in y while" is confusing.

Again, as I said, once you've mastered something, by definition you find it not confusing. Why should we doom x% of new users to writing a loop incorrectly at least once when we don't have to?

Ah, but if you’re not “doomed” to failing once, how will you ever master anything? Nobody knew how to write a C for-loop until someone showed them (and even then…). Nobody is going to just open a REPL and start writing code, with zero prior understanding of what Swift syntax looks like.

The thought here is along the lines of what Chris said, quoted above, and repeated here: "The extended C family of language [...] is an extremely popular and widely used set[;] programmers move around and work in different languages, and [aligning to expectations arising from other C family languages] allows a non-expert in the language to understand what is going on." By contrast, the `where` clause violates that expectation and I do not see "overwhelmingly large advantages" for doing so.

What about C#'s `where` then? As C# is a member of the C family languages `where` is not violating expectations!

Where is not exactly a part of c# it belongs to linq

And that is not a part of C#??

SQL is a domain-specific language, and LINQ is an internal domain-specific language with a language extension for C#. Neither is a general purpose language.

Your example actually goes to one of Laurent's points. Should the Swift core team or an enterprising community member propose a set of similarly powerful tools, along with a set of language extensions that add syntactic sugar for them, I (and I think Laurent, if I understand him correctly) would absolutely be in favor of such an addition. But as it is, `where` is an odd duckling. Just as you say, it looks like a component of a query language, but it does no such thing. In a for loop, it does some filtering, but until recently it functioned like a comma in `while` loops. Look at those other keywords which make this sugar possible in C#: in your example, `from` and `select`. We don't have any of that intrastructure in Swift.

IMHO the team has taken an Ockham Axe to the grammar: in the presence of multiple ways to produce the same or an acceptable stand-in (for eg when the only difference is an acceptable temporary perf setback), then the solution requiring the least assumptions on the compiler wins.

I would even extend this rule with the corollary that between an assumption materialized as a type checker rule and an assumption materialized as a full blown extra language keyword, there might be a bias to accept the former if it kills the latter. But this is just my personal inference of what their decision heuristic might be based solely on what I saw. My sole interest in trying to understand their decision making process is to try to avoid proposals that have little to no chance to go anywhere, as well as trying to present ones that will align better with where the language is going.

In this instance, WHERE is a heavy assumption on the compiler for no greater gain than filters can provide. So I think we save the WHERE keyword for an outcome that will be really worth it! Something along the idea of Linq, but with a proper Swift feel to it. What does it look like? I cannot say yet. But the good news is that having taken WHERE out now will make that next step a purely additive process (nothing will be taken out then, but a big thing will be gained).

The following is an example from MSDN with `where` clearly beaing a keyword:

var numQuery = from num in numbers where (num % 2) == 0 select num;

Here is food for your thoughts, you think WHERE is a keyword?! then look at this:

var numbers = new int{0,1,23,4,5,6,7,87,9};
var numQuery = from num in numbers where (num % 2) == 0 select num;

Program does not compile:

// Error CS1935: An implementation of `Where' query expression pattern could not be found. Are you missing `System.Linq' using directive or `System.Core.dll' assembly reference? (CS1935) (SessionsFinder)

using System.Linq;
var numbers = new int{0,1,23,4,5,6,7,87,9};
var numQuery = from num in numbers where (num % 2) == 0 select num;

That program does compiles and runs fine. This tells you that “where" is not at all the ordinary keyword that it appears to be. hence my “it is not C# per-se, it is Linq”. And if you still wonder, then rewrite the code so that “WHERE” no longer looks like a keyword:

var numQuery2 = numbers.Where( num => num %2 == 0); // exact same result as numQuery1

These are other real life examples from a OS X tool I wrote recently:

IEnumerable<Task<Session>> asyncOps = from session in sessions.Values select parseSessionDetails(updater, parser, session);
var ul = node.Descendants().Where(x => x.Name == "ul").First();

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

trs · June 12, 2016, 1:21pm

-1

* Swift is explicitly a C-family language. In most or all other C-family languages, for loop statements allow specification of conditions for exiting the loop but not for filtering. Therefore, Swift's use of `where` is unprecedented and needs to be learned anew by every user of Swift.

When was this decided? I distinctly remember some bloke under Craig Federighi’s hair saying that it was time to “move beyond” C and essentially ditch legacy conventions which no longer make sense.

I think you misunderstood my argument here. I don't mean that we should yoke ourselves to C conventions, and we should absolutely ditch C convention when it doesn't make sense. The big-picture argument here is that `where` doesn't pass the bar of correcting a C convention that no longer makes sense.

FWIW, on the topic of syntax choices, here is what Chris Lattner had to say on this list:

Kevin got it exactly right, but I’d expand that last bit a bit to:
“… picking the one that is most familiar to programmers in the extended C family is a good idea.["]
The extended C family of language (which includes C, C++, ObjC, but also C#, Java, Javascript, and more) is
an extremely popular and widely used set of languages that have a lot of surface-level similarity. I
don’t claim to know the design rationale of all of these languages, but I surmise that this is not an
accident: programmers move around and work in different languages, and this allows a non-expert in the
language to understand what is going on. While there are things about C that are really unfortunate IMO
(e.g. the declarator/declaration specifier part of the grammar) there is a lot of goodness in the basic
operator set, focus on dot syntax, and more.
I do agree that there are some benefits to ditching braces and relying on indentation instead, but there are
also downsides. Deviating from the C family in this respect would have to provide *overwhelmingly* large
advantages for us to take such a plunge, and they simply don’t exist.

As I understand it, Swift is a new language with new conventions. It is desirable to align as many of those as possible with existing conventions so as to be easily learned, but if you limit Swift to other languages conventions you deny it any identity. Did Python ask anybody’s opinion before dropping curly-braces? Did people learn whatever Perl is supposed to be? Look at C’s hieroglyphic for loops!

I don't think we disagree here.

Realistically, “for … in … while” is not going to cause incredible confusion. Removing it would cause a lot of frustration. You can’t on the one hand say our users are comfortable with the axioms of C’s hieroglyphic loops, and on the other hand say “for x in y while" is confusing.

Again, as I said, once you've mastered something, by definition you find it not confusing. Why should we doom x% of new users to writing a loop incorrectly at least once when we don't have to?

Ah, but if you’re not “doomed” to failing once, how will you ever master anything? Nobody knew how to write a C for-loop until someone showed them (and even then…). Nobody is going to just open a REPL and start writing code, with zero prior understanding of what Swift syntax looks like.

The thought here is along the lines of what Chris said, quoted above, and repeated here: "The extended C family of language [...] is an extremely popular and widely used set[;] programmers move around and work in different languages, and [aligning to expectations arising from other C family languages] allows a non-expert in the language to understand what is going on." By contrast, the `where` clause violates that expectation and I do not see "overwhelmingly large advantages" for doing so.

What about C#'s `where` then? As C# is a member of the C family languages `where` is not violating expectations!

Where is not exactly a part of c# it belongs to linq

And that is not a part of C#??

SQL is a domain-specific language, and LINQ is an internal domain-specific language with a language extension for C#. Neither is a general purpose language.

Your example actually goes to one of Laurent's points. Should the Swift core team or an enterprising community member propose a set of similarly powerful tools, along with a set of language extensions that add syntactic sugar for them, I (and I think Laurent, if I understand him correctly) would absolutely be in favor of such an addition. But as it is, `where` is an odd duckling. Just as you say, it looks like a component of a query language, but it does no such thing. In a for loop, it does some filtering, but until recently it functioned like a comma in `while` loops. Look at those other keywords which make this sugar possible in C#: in your example, `from` and `select`. We don't have any of that intrastructure in Swift.

IMHO the team has taken an Ockham Axe to the grammar: in the presence of multiple ways to produce the same or an acceptable stand-in (for eg when the only difference is an acceptable temporary perf setback), then the solution requiring the least assumptions on the compiler wins.

I would even extend this rule with the corollary that between an assumption materialized as a type checker rule and an assumption materialized as a full blown extra language keyword, there might be a bias to accept the former if it kills the latter. But this is just my personal inference of what their decision heuristic might be based solely on what I saw. My sole interest in trying to understand their decision making process is to try to avoid proposals that have little to no chance to go anywhere, as well as trying to present ones that will align better with where the language is going.

In this instance, WHERE is a heavy assumption on the compiler for no greater gain than filters can provide. So I think we save the WHERE keyword for an outcome that will be really worth it! Something along the idea of Linq, but with a proper Swift feel to it. What does it look like? I cannot say yet. But the good news is that having taken WHERE out now will make that next step a purely additive process (nothing will be taken out then, but a big thing will be gained).

I am all for extending `for` to be more like Scala’s `for`-expression or Haskell’s `do`-notation. LINQ might be too focused on querying.
Extending the current `where` to be syntax sugar for `filter` would be quite straightforward, though, so I’m not sure whether removing it first is really necessary.
That was not object of the pitch to retire `where` from `for`-loops, though. Instead the argument was (and still is) that `where` might be misunderstood there by beginners and should therefore be removed. This argument would apply to an extended `where` unchanged, because I can still write the exact same code as being criticized now and can even do more complicated things which would by even more hard to understand for beginners.
That’s the argument I disagree with.

The following is an example from MSDN with `where` clearly beaing a keyword:

var numQuery = from num in numbers where (num % 2) == 0 select num;

Here is food for your thoughts, you think WHERE is a keyword?! then look at this:

var numbers = new int{0,1,23,4,5,6,7,87,9};
var numQuery = from num in numbers where (num % 2) == 0 select num;

Program does not compile:

// Error CS1935: An implementation of `Where' query expression pattern could not be found. Are you missing `System.Linq' using directive or `System.Core.dll' assembly reference? (CS1935) (SessionsFinder)

using System.Linq;
var numbers = new int{0,1,23,4,5,6,7,87,9};
var numQuery = from num in numbers where (num % 2) == 0 select num;

That program does compiles and runs fine. This tells you that “where" is not at all the ordinary keyword that it appears to be. hence my “it is not C# per-se, it is Linq”.

Digging into C# Features That Support LINQ - C# | Microsoft Learn and C# Keywords - C# | Microsoft Learn tells me the following:
(1) `from`, `where` etc. are contextual keywords, but they are nonetheless keywords of C# and expressly *not* a specific feature of LINQ: "Although these new features are all used to a degree with LINQ queries, they are not limited to LINQ and can be used in any context where you find them useful."
(2) the compiler translates them into standard method calls (like Scala’s `for`-expression or Haskell’s `do`-notation). That is an integral part of C#.
(3) your error message originates from not having an implementation of a `Where`-method in scope. You could have provided one yourself instead of `using System.Linq`.

And if you still wonder, then rewrite the code so that “WHERE” no longer looks like a keyword:

var numQuery2 = numbers.Where( num => num %2 == 0); // exact same result as numQuery1

That’s exactly what I expected as it is the standard way syntactic language sugar is mapped to customizable behavior. Haskell’s `do`-notation or Scala’s `for`-expression are mapped likewise to functions on the types used.

-Thorsten

···

Am 12.06.2016 um 12:02 schrieb L Mihalkovic <laurent.mihalkovic@gmail.com>:

On Jun 11, 2016, at 11:45 PM, Xiaodi Wu <xiaodi.wu@gmail.com <mailto:xiaodi.wu@gmail.com>> wrote:
On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz <tseitz42@icloud.com <mailto:tseitz42@icloud.com>> wrote:
Am 11.06.2016 um 22:29 schrieb L. Mihalkovic <laurent.mihalkovic@gmail.com <mailto:laurent.mihalkovic@gmail.com>>:

On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

On Fri, Jun 10, 2016 at 6:10 AM, Karl <razielim@gmail.com <mailto:razielim@gmail.com>> wrote:

These are other real life examples from a OS X tool I wrote recently:

IEnumerable<Task<Session>> asyncOps = from session in sessions.Values select parseSessionDetails(updater, parser, session);
var ul = node.Descendants().Where(x => x.Name == "ul").First();

xwu · June 13, 2016, 3:16pm

I’m just (probably obtusely) suggesting that there are different levels
and styles of expression and that the existence of one does not render
other styles invalid.

In relation to the “where” debate, the fact that you can express
everything with “guard” or “if” as you can with “where” is not, in my mind,
a strong argument against “where” because it ignores other more intangible
aspects that are going to be a lot harder to quantify since they depend on
the context of the problem, the surrounding code, the mindset of the
writer, and the assumed mindset of the reader.

I don’t dispute that we *could* live without “where” - that is not the
point. We could also live without classes or generics or any of a variety
of other features - but why should we when we don’t have to?

I'm not sure where this comes in. I was clarifying what I mean when I call
a language construct 'expressive.' As I understand the term, `where` is not
expressive, whereas classes and generics are expressive.

Perhaps this is due to English not being my first language, but I go by
the dictionary definition of expressive:

expressive (adjective) - effectively conveying thought or feeling.

And I believe that for-in-where is expressing the condition more
effectively (and efficiently) than adding if/guard-continue into the actual
code block.

That's fine for English, but I just mean that in a language design context
I've always understood the word to encompass the *breadth* of thoughts that
can be expressed. In that sense, `where` might express one thing
economically, but it cannot express very many things at all, no matter how
much text you write in a `where` clause.

···

On Mon, Jun 13, 2016 at 9:54 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:

On Jun 13, 2016, at 4:46 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Mon, Jun 13, 2016 at 9:28 AM, Sean Heber <sean@fifthace.com> wrote:

l8r
Sean

> On Jun 13, 2016, at 9:19 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> How do you mean? I don't follow.
> On Mon, Jun 13, 2016 at 09:11 Sean Heber <sean@fifthace.com> wrote:
> > On Jun 13, 2016, at 9:05 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote:
> >
> > On Mon, Jun 13, 2016 at 8:58 AM, Charlie Monroe < >> charlie@charliemonroe.net> wrote:
> > if-continue. But I gladly took upon for-in-where as soon as I found
out about it since it's more expressive and simply is less typing.
> >
> > I don't think we use the term 'expressive' in the same way. I
understand it to mean that permitting the expression of more things. But of
course, `where` does only a subset of `guard...continue` or
`if...continue`; thus, less expressive.
>
> The fact that you could simply use the words “I am happy” to express
the concept of being happy does not mean that writing a complex poem that
also conveys happiness should therefore be prohibited.
>
> l8r
> Sean
>

Brent_Royal-Gordon · June 13, 2016, 7:59pm

See the benchmarks me and Erica have posted here a few days back - even with the lazy accessor, if you decided to use filter(_:), you lost 10+% of performance. Correct way to do this without `where` and without performance penalization is to use guard within the for-in loop.

10% on a microbenchmark repeater 4000000 times is hardly a justification for going on way or the other.

You're right: 10% on a microbenchmark isn't the best possible data. If you have better data, we are all ears.

···

--
Brent Royal-Gordon
Architechies

let_var_go · June 13, 2016, 3:23pm

I am 100% with Charlie on this. Expressiveness has to do with the
*effectiveness* of conveying a thought or a feeling.

Keep "where". It is expressive. It conveys a specific idea effectively and
concisely.

···

On Mon, Jun 13, 2016 at 7:54 AM Charlie Monroe via swift-evolution < swift-evolution@swift.org> wrote:

On Jun 13, 2016, at 4:46 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Mon, Jun 13, 2016 at 9:28 AM, Sean Heber <sean@fifthace.com> wrote:

I’m just (probably obtusely) suggesting that there are different levels
and styles of expression and that the existence of one does not render
other styles invalid.

In relation to the “where” debate, the fact that you can express
everything with “guard” or “if” as you can with “where” is not, in my mind,
a strong argument against “where” because it ignores other more intangible
aspects that are going to be a lot harder to quantify since they depend on
the context of the problem, the surrounding code, the mindset of the
writer, and the assumed mindset of the reader.

I don’t dispute that we *could* live without “where” - that is not the
point. We could also live without classes or generics or any of a variety
of other features - but why should we when we don’t have to?

I'm not sure where this comes in. I was clarifying what I mean when I call
a language construct 'expressive.' As I understand the term, `where` is not
expressive, whereas classes and generics are expressive.

Perhaps this is due to English not being my first language, but I go by
the dictionary definition of expressive:

expressive (adjective) - effectively conveying thought or feeling.

And I believe that for-in-where is expressing the condition more
effectively (and efficiently) than adding if/guard-continue into the actual
code block.

l8r
Sean

> On Jun 13, 2016, at 9:19 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
>
> How do you mean? I don't follow.
> On Mon, Jun 13, 2016 at 09:11 Sean Heber <sean@fifthace.com> wrote:
> > On Jun 13, 2016, at 9:05 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote:
> >
> > On Mon, Jun 13, 2016 at 8:58 AM, Charlie Monroe < >> charlie@charliemonroe.net> wrote:
> > if-continue. But I gladly took upon for-in-where as soon as I found
out about it since it's more expressive and simply is less typing.
> >
> > I don't think we use the term 'expressive' in the same way. I
understand it to mean that permitting the expression of more things. But of
course, `where` does only a subset of `guard...continue` or
`if...continue`; thus, less expressive.
>
> The fact that you could simply use the words “I am happy” to express
the concept of being happy does not mean that writing a complex poem that
also conveys happiness should therefore be prohibited.
>
> l8r
> Sean
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

let_var_go · June 13, 2016, 3:44pm

I think we must be reading different discussions.

What I have seen in this discussion is the following:

a) The need to filter a for-in loop doesn't arise that often; but,
b) When it does arise, everyone who has chimed in on this thread (except
the two people who are proposing the change) thinks that the "where" clause
is the clearest, most expressive way to do it.

Something that would help me get on board with this change is more evidence
about what kind of problems it is actually creating.

As best I can tell, this proposal got started because "somewhere" some new
programmers (no one knows how many) expressed some confusion (no one knows
how seriously they were confused, or how long it took them to figure it
out) about how the where clause worked in a for-in loop. For all we know,
once they learned the way it works, they may have said, "Hey that's cool!
I'm gonna use that from now on!"

In other words, you seem to be talking about removing a feature that is
liked by *a lot* people, based on some unsubstantiated reports of user
error that may or may not have been totally unsubstantial.

I don't want new programmers to be confused, either, but the "where" clause
is such a basic programming construct - the keyword is new, but the idea
itself is as old as programming - that I don't mind expecting new
programmers to learn how to use it. The learning curve should be incredibly
short - it is nothing more than a filter operation.

There's something else here that is really important to me, though I don't
know how others feel about it.

Using the guard...continue approach that you are promoting is a code smell.
It puts control-flow logic inside the for-in loop. That is something I have
always tried to avoid. I know that the language allows for it, but I
believe it is bad programming practice. In fact, if you get rid of the
`where` keyword, I'm still not going to use guard...continue. I'll just
filter the collection first and then loop it.

It is a code smell for the same reason that messing with the index inside a
for;; loop was a code smell. I was always taught never to do this:

for var i = 0; i < array.count, i++ {
  if iWantThisToLoopAnExtraTime {
    i--
  }
}

Why? Because code like that is confusing. It becomes difficult to know how
many times the loop will execute, what the looping logic is, etc. Sure, I
might get away with it most of the time, but it is bad practice and there
is always a better way to do what you want to do. The only thing that keeps
you from the better way is laziness.

The same is true (albeit to a lesser degree) for the guard...continue. It
may not be as extreme, but it is still a code smell. It divides the
control-flow logic into two parts - one outside the loop, and one inside
the loop, and it suddenly becomes twice as easy to miss something.

Using for-in-where, all of the control-flow logic is on one single line,
and once it is known that "where" operates as a filter operation, it all
works together in a single, harmonious statement that declares exactly what
is going to happen in a way that is totally unambiguous.

So by getting rid of the "where" clause, I believe that you are actually
encouraging bad programming practice. Instead of encouraging the new user
to learn this very simple construct that will ultimately make their code
safer and more expressive without dividing their control-flow logic
unnecessarily into two separate parts, you are encouraging them to just "do
what they know". I think that is terrible, and you are doing them a
disservice.

And from a personal standpoint, you are telling me that I have to write
smelly code, even though there is this perfectly good non-smelly option
sitting right there, because you don't want someone else to have to learn
something.

···

On Mon, Jun 13, 2016 at 5:29 AM Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

I think this discussion has made it pretty plain that what is claimed to
be 'so useful' is barely ever used. Moreover, it provides no independent
uses. The point of these pitches is to sound out arguments, not, as far as
I was aware, to take a vote.

On Mon, Jun 13, 2016 at 1:54 AM Jose Cheyo Jimenez <cheyo@masters3d.com> > wrote:

--1

I think it would be a waste of the community's time to do a formal review
when only two people are in favor of this removal.

'for in where' is so useful especially since we don't have for;;; loops
anymore. I'd say leave this alone; the majority doesn't want this changed.

On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@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.

On Fri, Jun 10, 2016 at 12:10 let var go <letvargo@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@swift.org> wrote:

On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________

swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Haravikk3 · June 13, 2016, 5:24pm

I think that the discussion has made it clear that far more people want this feature to remain, and feel it is a valid part of the language, whether or not it’s a mainly aesthetic one, and that it should stay. Whether or not the discussion is intended as a vote is irrelevant, if more people want a feature to remain than want it removed then that suggests the justification for removing it had better be a really good one.

So far we have redundancy, which isn’t really sufficient reason to remove something, as we have plenty of redundant syntax for convenience. Take conditional binding for example, which is essentially just a shorthand for pattern matching. Functionally they’re identical, and there’s not much difference in complexity (you don’t have to learn the pattern matching aspect in order to use it for unwrapping optionals), so really it’s just a neat shorthand similar to where, and could be removed easily, yet people would fight against it just as furiously.

Otherwise the argument is against confusion/mistakes, but this alone isn’t a reason to remove a feature vs addressing why confusion is caused. Besides, the main argument for it being confusing comes from its use in both while and for loops, but if it’s being removed from while loops then this ceases to be an issue. As a result it would be premature to remove the feature as we don’t know yet if it’s still confusing when only permitted on for loops.

After that the other issue is whether filtering deserves a special case, but this is muddied by a lack of use largely resulting from lack of awareness. For us to get useful evidence either way would require this to put more widely known and to see if it continues to be used infrequently; I know about the keyword and use it in maybe 20% of my for loops (plus I actually rarely use while loops, and mainly in testing).
Besides which there is a proposal for a variant of where (while/until) which gives access to another fairly common variant of if/guard that developers may wish to replace, which would address a lack of versatility.

The benefit of the where clause is eliminating a line by putting the same condition on the opening loop, you may not consider this worthwhile but clearly plenty of people do, therefore I’d consider this justification enough for the feature to remain as we find it useful and prefer how our code looks with this shorthand. You remain free as ever to not use it.

···

On 13 Jun 2016, at 13:28, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

I think this discussion has made it pretty plain that what is claimed to be 'so useful' is barely ever used. Moreover, it provides no independent uses. The point of these pitches is to sound out arguments, not, as far as I was aware, to take a vote.