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

[xwu (Xiaodi Wu)]

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.

···

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

Brandon

Sent from my iPad

On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution < > 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> 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> 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

[xwu (Xiaodi Wu)]

Sent from my iPad

Are you really surprised that some people don't want this taken away?

Nope, that's to be expected.

The burden should be on those that want it taken out of the language and
not those that want it kept. After all something is being removed and it
should be a delicate process.

Agreed. We who think it's better to take this syntax out have advanced an
argument with several prongs. Namely, that the `where` clause serves no
independent purpose;

What does this mean or matter?

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

that a more general solution has already been added to the language (as
well as another in the stdlib);

We have sugar all over the place to make features more palatable

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

that the `where` clause is not necessary for progressive disclosure to new
users before they're ready for the general solution;

I have no clue what this is suppose to mean

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

that it is, at present, rarely used in practice;

It was added in the official release less than a year ago and it's not
really documented well. And I'm not convinced it's rarely used in practice
especially when it's exactly what you want

I've endeavored to outline why it's rarely exactly what you want. Whether
you buy it or not, well, that's another matter.

that it has no analog in other commonly used general purpose languages in
the C family;

Why is this a good argument for its removal?

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

that it is the remnant of a direction in which the core team later decided

not to pursue;

I don't know anything about this but it sure seemed at one point they
really liked where. It had to have gone through their own rigorous review
process to be added in the first place?

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

and that, given its lack of utility, lack of use, and vestigial state,

Another opinion. This doesn't seem like a definitive argument for its
removal

This is a summation of the prongs mentioned above.

being the cause of confusion even among a small number of users (if their

···

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

On Jun 13, 2016, at 9:36 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope <bknope@me.com> wrote:
number be small) is grounds to conclude that it is harmful to the language
and therefore ought to be removed.

"Harmful to the language" seems a bit extreme.

I would love to hear more from the core team on this but I know they are
just too busy right now

Brandon

Don't be surprised when the defenders say it is more readable to them.
That is a *sound* argument in my opinion.

IMO, it cannot stand on its own as a complete argument for saving a
feature in the face of the arguments we've advanced. Couldn't you say the
same for `++` or `for;;` loops? I'd say our case is at least as strong as
that for `for;;` loops. By comparison, if I recall, the `for;;` loop was
argued to be ill-fitting the rest of the language and lacking in usage, but
it certainly had utility independent of `for...in` loops and was well
precedented in C languages.

Brandon

Sent from my iPad

On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@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> 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> 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

[BigZaphod (Sean Heber)]

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

···

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.

[Brandon_Knope]

Are you really surprised that some people don't want this taken away?

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.

Don't be surprised when the defenders say it is more readable to them. That is a *sound* argument in my opinion.

Brandon

···

Sent from my iPad

On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution <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> 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> 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

[xwu (Xiaodi Wu)]

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.

···

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
>

[Brandon_Knope]

Are you really surprised that some people don't want this taken away?

Nope, that's to be expected.

The burden should be on those that want it taken out of the language and not those that want it kept. After all something is being removed and it should be a delicate process.

Agreed. We who think it's better to take this syntax out have advanced an argument with several prongs. Namely, that the `where` clause serves no independent purpose;

What does this mean or matter?

that a more general solution has already been added to the language (as well as another in the stdlib);

We have sugar all over the place to make features more palatable

that the `where` clause is not necessary for progressive disclosure to new users before they're ready for the general solution;

I have no clue what this is suppose to mean

that it is, at present, rarely used in practice;

It was added in the official release less than a year ago and it's not really documented well. And I'm not convinced it's rarely used in practice especially when it's exactly what you want

that it has no analog in other commonly used general purpose languages in the C family;

Why is this a good argument for its removal?

that it is the remnant of a direction in which the core team later decided not to pursue;

I don't know anything about this but it sure seemed at one point they really liked where. It had to have gone through their own rigorous review process to be added in the first place?

and that, given its lack of utility, lack of use, and vestigial state,

Another opinion. This doesn't seem like a definitive argument for its removal

being the cause of confusion even among a small number of users (if their number be small) is grounds to conclude that it is harmful to the language and therefore ought to be removed.

"Harmful to the language" seems a bit extreme.

I would love to hear more from the core team on this but I know they are just too busy right now

Brandon

···

Sent from my iPad

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

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

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> 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> 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> 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

[xwu (Xiaodi Wu)]

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> 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> 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

[Charlie_Monroe1 (Charlie Monroe)]

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.

···

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

[xwu (Xiaodi Wu)]

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

[Charlie_Monroe1 (Charlie Monroe)]

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.

···

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 <mailto: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 <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

[VladimirS (Vladimir)]

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).

*Filtering* is another important operation we often need during the iteration of collection. 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).

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.

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

[xwu (Xiaodi Wu)]

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 12:30 PM, let var go <letvargo@gmail.com> wrote:

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

[xwu (Xiaodi Wu)]

I don't think the 'where' in 'for' loop adds another dialect of Swift more
than using of [Int] vs Array<Int> or shorthand syntax for Optionals adds
it. (in addition to 'guard' vs 'if')

As I mentioned above, `guard` and `if` each have uses that cannot be served
by the other. Shorthand syntax for optional types serves, among other
purposes, the aim of progressive disclosure of language features to
learners (in the sense that a beginning user doesn't have to learn about
enums before using optionals). syntax for arrays is long precedented
from other languages in the C family and satisfies user expectations when
they come from those languages. I acknowledge that meeting user
expectations when they come from a related language, as well as learning
and education, are valid aims. And I have put forward arguments that
`where` does not serve any of these valid ends.

So, it's just an opinion if 'where' in 'for' loop introduces new dialect
or if it is a handy feature that can be used when it best suits the needs
in some situation or even a metter of style(like [Int] vs Array<Int> or
using .forEach vs for-in etc).

But, `.forEach` cannot be used if you want to prematurely break from the
loop, so again it cannot do what `for...in` can do. By contrast, `guard`
can do everything `where` can do and more. Moreover, here we are talking
about two aspects of the grammar, whereas `.forEach` is an stdlib method.
As I've argued before, users expect to see functions they aren't familiar
with--after all, any person can write a function and name it anything--but
it elevates the learning curve to have keywords and syntaxes in the
language itself which are redundant.

···

On Fri, Jun 10, 2016 at 1:09 PM, Vladimir.S <svabox@gmail.com> wrote:

On 10.06.2016 20:17, Xiaodi Wu via swift-evolution 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 >> <mailto: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 <mailto:swift-evolution@swift.org>> wrote:

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

[Christopher_Kornher1 (Christopher Kornher)]

I don't think the 'where' in 'for' loop adds another dialect of Swift more than using of [Int] vs Array<Int> or shorthand syntax for Optionals adds it. (in addition to 'guard' vs 'if')
So, it's just an opinion if 'where' in 'for' loop introduces new dialect or if it is a handy feature that can be used when it best suits the needs in some situation or even a metter of style(like [Int] vs Array<Int> or using .forEach vs for-in etc).

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.

  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.

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.

Programming styles are not dialects.

···

On Jun 10, 2016, at 12:09 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
On 10.06.2016 20:17, Xiaodi Wu via swift-evolution wrote:

On Fri, Jun 10, 2016 at 12:10 let var go <letvargo@gmail.com >> <mailto:letvargo@gmail.com>> wrote:
  On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
      On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

          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 <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

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

[xwu (Xiaodi Wu)]

I'm sorry, but until this discussion I had never heard of a coding style
that advocates for conservation of vertical space. There's a lot of
argument whether 80 characters is still a relevant line length, but I've
never heard discussion that a single long line is better than multiple
lines as a general principle.

We’re not talking about a single super long line here, my actual uses of
for in where don’t get much longer than the examples I’ve given, besides
which the where keyword itself does a good job of breaking up the line into
distinct pieces. Compared to say a long line full of chained .filter and
.map or whatever it’s very clean.

At no point am I advocating shoving everything onto one line just for the
sake of it, however, without a where clause a for in loop’s opening line
tends to be very short so it leaves a nice chunk of extra space that’s
ideal for a simple condition. Anything longer can, and absolutely should,
span multiple lines in whatever form the developer prefers, no-one is
suggesting that where clauses should remain in so we can ruin our code by
shoving as much as possible on one line.

Here, though emotion is hardly a worthy barometer, 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.

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.

But it does show that (a) it's obscure; and (b) if it were never there,
approximately no one outside this list would miss it. However, given that
it is there, the large proportion of people who don't know of it
are nonetheless liable to *read* it, and they stand a chance of
misinterpreting its meaning on first reading. They may encounter it at any
time, since it's a part of the language itself and not domain-specific, but
they might well encounter this syntax only once in a blue moon and far into
their time using the language. Thus, the need to weigh pros and cons here I
think.

Plus a lot of developers are coming from other languages where nothing
like this existed, so if they don’t discover it somewhere it’s not
surprising if they don’t use it. Also, the important figures aren’t
actually for in versus for in where, what’s needed is a count of for in
where versus loops that use either if/guard continue (not break) or
.filter() (i.e- only loops that *could* use a where clause but don’t).

Right, that might be the more salient statistic.

···

On Fri, Jun 10, 2016 at 3:17 PM, Haravikk <swift-evolution@haravikk.me> wrote:

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

Most for in loops visit every element so it’s not surprising that they
outnumber for in where by a large margin. I use it quite a bit in place of
.filter(), and I’d use this form even more if there were a breaking
alternative, I probably wouldn’t use a combined filtering and breaking
version much though, but I wouldn’t be opposed to the possibility.

[Panajev (Goffredo Marocchi)]

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.

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

[xwu (Xiaodi Wu)]

-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.

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.

···

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:

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

[xwu (Xiaodi Wu)]

* 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`).

···

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:

-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

[trs (Thorsten Seitz)]

-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.

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

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.

-Thorsten

···

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:

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

[L_Mihalkovic]

-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();

···

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 <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: