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

[Charlie_Monroe1 (Charlie Monroe)]

I saw your post on that *after* I finished sending this. Moving `where` next to the pattern, like you'd find in `catch` and switch `case`, the code would look like this:

for i where i % 2 == 0 in sequence {
    // do stuff
}

This is the best version yet - the placement of 'where' makes total sense and I really like it there.

I really like how it aligns with case statements better. BUT I think using guard is still better because
there's still user confusion between "does this terminate" and "does this filter".

Guard use is unambiguous.

It may seem superfluous, but what about something like

for i in sequence where i % 2 == 0 else continue {
  /// do stuff
}

for i in sequence where i % 2 == 0 else break {
  /// do stuff
}

Which would make it explicit whether the for-loop should filter or break, yet it's still a one-liner...

···

On Jun 9, 2016, at 7:15 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 8, 2016, at 10:17 PM, Sean Heber <sean@fifthace.com <mailto:sean@fifthace.com>> wrote:
On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

-- E

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

[Erica_Sadun]

I need to correct this misapprehension.
My suggested alternative to where was and remains `guard`.

-- E

···

On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.

[Jon_Shier]

As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is the perfect example of this. No one will find the use of “where” in loops confusing, aside from those who will wonder why it was removed from if statements. There is no misleading behavior or confusing syntax here. This is just consistency for consistency’s sake. Once this proposal is done, then another will be made to remove “where” from another place in the language. Then another and another until it’s gone completely and a very useful part of the language is removed in the name of consistency. Which really just comes down to “where” isn’t used here, so it can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

···

On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.

I need to correct this misapprehension.
My suggested alternative to where was and remains `guard`.

-- E

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

[xwu (Xiaodi Wu)]

There have been, in previous threads, several examples given where users of
Swift have found the behavior of `where` to be misleading and confusing.

In fact, the first of these proposals began with a question: how does one
write arbitrary Boolean assertions after a let binding? The answer (use
`where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose
other than an academic consistency.

···

On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution < swift-evolution@swift.org> wrote:

        As time goes on, I’m feeling more and more that these consistency
proposals are sorely misguided. Frankly, unless the syntax is confusing or
misleading, even once the developer has learned the guiding principles of
Swift, consistency is not a good argument for change. This proposal is the
perfect example of this. No one will find the use of “where” in loops
confusing, aside from those who will wonder why it was removed from if
statements. There is no misleading behavior or confusing syntax here. This
is just consistency for consistency’s sake. Once this proposal is done,
then another will be made to remove “where” from another place in the
language. Then another and another until it’s gone completely and a very
useful part of the language is removed in the name of consistency. Which
really just comes down to “where” isn’t used here, so it can’t be used
there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> > wrote:
>> See my latest post - included results with -Ofast. But still, using
filter and lazy.filter is 10+% slower, which were the suggested
alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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

[Dany_St-Amant]

There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica, I have do not recall hearing that many voices saying that 'where' is confusing. Yes, there's was maybe even less voices stating that it is not confusing, but which group is more vocal?

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for .. in .., continue if not matching).

I know there's a linguist on the list, maybe he could comment on whether or not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first, that it warrant removal from the language. The by-value/by-reference is well define, but can be confusing at first. Same goes for eager/lazy processing, or escaping vs non-escaping closure, or even the difference between closure and function. But no one suggest to remove them.

Dany

···

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> a écrit :

In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use `where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose other than an academic consistency.

On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <swift-evolution@swift.org> wrote:
        As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is the perfect example of this. No one will find the use of “where” in loops confusing, aside from those who will wonder why it was removed from if statements. There is no misleading behavior or confusing syntax here. This is just consistency for consistency’s sake. Once this proposal is done, then another will be made to remove “where” from another place in the language. Then another and another until it’s gone completely and a very useful part of the language is removed in the name of consistency. Which really just comes down to “where” isn’t used here, so it can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
>> See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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)]

Sorry, meant alternatives that didn't require any additional code in the body of the for loop.

···

On Jun 9, 2016, at 7:16 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.

I need to correct this misapprehension.
My suggested alternative to where was and remains `guard`.

-- E

[xwu (Xiaodi Wu)]

There have been, in previous threads, several examples given where users
of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica,
I have do not recall hearing that many voices saying that 'where' is
confusing.

Shawn Erickson wrote this to the list just yesterday:

"I support your position on the use of where and while/when being confusing
in the loop statement. I (and I know others) have for example used where in
a loop statement mistakenly thinking it would terminate the loop early but
of course learned that it basically filters what causes the loop body to be
executed. After the fact that made sense to me but it didn't click at
first."

Yes, there's was maybe even less voices stating that it is not confusing,
but which group is more vocal?

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for ..
in .., continue if not matching).

I'm glad that you find it very clear. I do as well. That does not mean it
is clear to everyone.

I know there's a linguist on the list, maybe he could comment on whether
or not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first,
that it warrant removal from the language.

It is a very bad sign if something is confusing at first, especially to a
significant proportion of users. It's true by definition that once you have
mastered something you are no longer confused by it.

As has been stated on this list, education is a valid and important
consideration for Swift. If something is confusing rather than difficult
(and the *concept* of filtering a list is not at all a difficult concept),
and if the same underlying concept can already be invoked in alternative
and equivalent ways that are not confusing, then it's a no-brainer that the
confusing thing is harmful to the language and should be removed on that
basis alone.

By analogy, Chinese and Japanese share difficult writing systems. Yet many
people use those languages daily without difficulty. Does that mean there's
not a problem? Far from it: in fact, you'll find that many intelligent
people have devoted their life's work to mitigating the issue. Both Chinese
and Japanese underwent a round of simplification in the 20th century. Think
about it: real languages used for daily life by a significant fraction of
the world's population were revamped for the purpose of increasing
accessibility to new learners.

The by-value/by-reference is well define, but can be confusing at first.

Same goes for eager/lazy processing, or escaping vs non-escaping closure,
or even the difference between closure and function. But no one suggest to
remove them.

Value types vs. reference types is a concept (and a moderately advanced
one), eager vs. lazy processing is a concept (and a moderately advanced
one), and closures are a concept (and definitely an advanced one).

Filtering a collection is a concept as well, and no one is suggesting its
removal. We are proposing to simplify and rationalize the syntax by which
filtering is invoked. If there were a way to dramatically simplify the
syntax surrounding value types and reference types so as to diminish
confusion, you can absolutely guarantee that there would be proposals to
change the syntax. If I could think of one tomorrow, you'd see a thread
tomorrow about it. I don't think I'm that smart though.

···

On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> a écrit :

Dany

In fact, the first of these proposals began with a question: how does one
write arbitrary Boolean assertions after a let binding? The answer (use
`where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose
other than an academic consistency.
On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution < > swift-evolution@swift.org> wrote:

        As time goes on, I’m feeling more and more that these consistency
proposals are sorely misguided. Frankly, unless the syntax is confusing or
misleading, even once the developer has learned the guiding principles of
Swift, consistency is not a good argument for change. This proposal is the
perfect example of this. No one will find the use of “where” in loops
confusing, aside from those who will wonder why it was removed from if
statements. There is no misleading behavior or confusing syntax here. This
is just consistency for consistency’s sake. Once this proposal is done,
then another will be made to remove “where” from another place in the
language. Then another and another until it’s gone completely and a very
useful part of the language is removed in the name of consistency. Which
really just comes down to “where” isn’t used here, so it can’t be used
there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution < >> swift-evolution@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> >> wrote:
>> See my latest post - included results with -Ofast. But still, using
filter and lazy.filter is 10+% slower, which were the suggested
alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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

[Lmpessoa (Leonardo Pessoa)]

I would vow to remove where clauses altogether. Most of the times I used it in ifs, fors and switches I ended up thinking it hardened readability of my code (perhaps because of placement, but I do not think alternatives made it more readable) and so it was my decision to stop using where whenever possible in my code. Since Erica's performance test pointed out using guard is nearly as fast as using where and the core team is removing wheres from ifs, I think the ones in fors could go next.

L

···

On 10 Jun 2016, at 2:01 am, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 9, 2016, at 7:16 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.

I need to correct this misapprehension.
My suggested alternative to where was and remains `guard`.

-- E

Sorry, meant alternatives that didn't require any additional code in the body of the for loop.

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

[trs (Thorsten Seitz)]

There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica, I have do not recall hearing that many voices saying that 'where' is confusing. Yes, there's was maybe even less voices stating that it is not confusing, but which group is more vocal?

+1

In addition there have been quite a few voices stating that they like `where` and do not find it confusing.

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Yes, that is just the same order as in Swift's `for` loop and in mathematics.
And the same semantics (filtering). No confusion there at all.

-Thorsten

···

Am 10.06.2016 um 04:45 schrieb Dany St-Amant via swift-evolution <swift-evolution@swift.org>:

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> a écrit :

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for .. in .., continue if not matching).

I know there's a linguist on the list, maybe he could comment on whether or not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first, that it warrant removal from the language. The by-value/by-reference is well define, but can be confusing at first. Same goes for eager/lazy processing, or escaping vs non-escaping closure, or even the difference between closure and function. But no one suggest to remove them.

Dany

In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use `where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose other than an academic consistency.

On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <swift-evolution@swift.org> wrote:
        As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is the perfect example of this. No one will find the use of “where” in loops confusing, aside from those who will wonder why it was removed from if statements. There is no misleading behavior or confusing syntax here. This is just consistency for consistency’s sake. Once this proposal is done, then another will be made to remove “where” from another place in the language. Then another and another until it’s gone completely and a very useful part of the language is removed in the name of consistency. Which really just comes down to “where” isn’t used here, so it can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
>> See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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

[Brandon_Knope]

There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica, I have do not recall hearing that many voices saying that 'where' is confusing.

Shawn Erickson wrote this to the list just yesterday:

"I support your position on the use of where and while/when being confusing in the loop statement. I (and I know others) have for example used where in a loop statement mistakenly thinking it would terminate the loop early but of course learned that it basically filters what causes the loop body to be executed. After the fact that made sense to me but it didn't click at first."

Couldn't we find examples of anyone being confused at any syntax? Especially with an unfamiliar construct in a new language.

If people find the new proposed syntax confusing, do we pull that too? At what point do we stop?

Yes, there's was maybe even less voices stating that it is not confusing, but which group is more vocal?

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for .. in .., continue if not matching).

I'm glad that you find it very clear. I do as well. That does not mean it is clear to everyone.

I still have yet to see widespread confusion of this. A few people learning swift here or there, but once they learn the syntax...do they still find it confusing?

I expect some concrete data on stuff like this...especially with proposed syntax changes.

Without concrete examples, what would stop one from coming in here and waving their hands around to push *what they like* through?

I know there's a linguist on the list, maybe he could comment on whether or not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first, that it warrant removal from the language.

It is a very bad sign if something is confusing at first, especially to a significant proportion of users. It's true by definition that once you have mastered something you are no longer confused by it.

Again, where is this significant proportion of users? I don't mean to hound you on this, but I am genuinely curious where this is all coming from.

The burden of evidence is on the proposers of these ideas.

As has been stated on this list, education is a valid and important consideration for Swift. If something is confusing rather than difficult (and the *concept* of filtering a list is not at all a difficult concept), and if the same underlying concept can already be invoked in alternative and equivalent ways that are not confusing, then it's a no-brainer that the confusing thing is harmful to the language and should be removed on that basis alone.

What is clear to one person may be confusing to another. There is no perfect syntax that will not make it confusing for some users.

···

On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> a écrit :

----

I really think it is important to come armed with more information with these proposals. It's easy to say a significant proportion of people are confused but it would make me much more comfortable to see this data to back it up.

What if we are spinning our wheels for no reason on a feature that *most* don't find confusing? What if we make a bigger proportion of those who did understand it more confused now?

Brandon

By analogy, Chinese and Japanese share difficult writing systems. Yet many people use those languages daily without difficulty. Does that mean there's not a problem? Far from it: in fact, you'll find that many intelligent people have devoted their life's work to mitigating the issue. Both Chinese and Japanese underwent a round of simplification in the 20th century. Think about it: real languages used for daily life by a significant fraction of the world's population were revamped for the purpose of increasing accessibility to new learners.

The by-value/by-reference is well define, but can be confusing at first. Same goes for eager/lazy processing, or escaping vs non-escaping closure, or even the difference between closure and function. But no one suggest to remove them.

Value types vs. reference types is a concept (and a moderately advanced one), eager vs. lazy processing is a concept (and a moderately advanced one), and closures are a concept (and definitely an advanced one).

Filtering a collection is a concept as well, and no one is suggesting its removal. We are proposing to simplify and rationalize the syntax by which filtering is invoked. If there were a way to dramatically simplify the syntax surrounding value types and reference types so as to diminish confusion, you can absolutely guarantee that there would be proposals to change the syntax. If I could think of one tomorrow, you'd see a thread tomorrow about it. I don't think I'm that smart though.

Dany

In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use `where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose other than an academic consistency.

On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <swift-evolution@swift.org> wrote:
        As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is the perfect example of this. No one will find the use of “where” in loops confusing, aside from those who will wonder why it was removed from if statements. There is no misleading behavior or confusing syntax here. This is just consistency for consistency’s sake. Once this proposal is done, then another will be made to remove “where” from another place in the language. Then another and another until it’s gone completely and a very useful part of the language is removed in the name of consistency. Which really just comes down to “where” isn’t used here, so it can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
>> See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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

[lorentey (Karoy Lorentey)]

Interestingly, I find where clauses in `for` to be a useful tool to *improve* readibility. To me, it flows much better to write & read this:

    for (start, duration) in days where calendar.isDateInWeekend(start) {
        ...
    }

rather than this:

  for (start, duration) in days {
        guard calendar.isDateInWeekend(start) else { continue }
        ...
    }

or this:

  for (start, duration) in days.filter({ calendar.isDateInWeekend($0.0) }) {
    ...
  }

Of these three, I'd argue the first is the easiest to understand for a person who's never seen Swift code before. (Admittedly I doubt that's something languages should be optimized for, though.) The extra punctuation and the use of $0 instead of the loop's bindings makes the third approach seem especially noisy & scary.

Obviously, editorial tools like this aren't essential, and I could easily adapt to live without such syntactic sugar. But I do not like the idea of systematically ridding the language of such charming constructs when there is no technical reason to do so. SE-0099 fixed a technical problem with the syntax of a shorthand construct, without removing it from the language. It did not bring back Swift 1's `if` pyramids.

Moreover, Erica is absolutely right about `switch`: while `where` clauses are arguably non-essential in `for` loops, `switch` statements would lose a great deal of their expressive power without them. For example, in the following snippet (taken from a lexer in SwiftPM), all cases are logically at the same level. I think it's a win that Swift allows them to be expressed as such, and I'd strongly object to a proposal that removed this capability.

    switch c {
    case UInt8(ascii: "\n"): ...
    case UInt8(ascii: "#"): ...
    case let c where c.isSpace(): ...
    case UInt8(ascii: "\""): ...
    case let c where c.isNumberInitialChar(): ...
    case let c where c.isIdentifierChar(): ...
    case UInt8(ascii: ","): ...
    case UInt8(ascii: "="): ...
    case UInt8(ascii: "["): ...
    case UInt8(ascii: "]"): ...
    case UInt8(ascii: "."): ...
    default: ...
    }

Obviously, we could rewrite this to use a single `if` ladder, but I think most would not find that an improvement.

(The same argument applies to `catch` statements, although with less force.)

As long as `where` is kept in `switch` and `catch`, and as long the grammar is unambiguous, I think there is little point to removing where clauses from `for`. To improve consistency, I'd not mind if SE-0099 kept `where` as an alternative way to spell `,` in `if` statements, too.

···

On 2016-06-10 11:39:34 +0000, Leonardo Pessoa via swift-evolution said:

I would vow to remove where clauses altogether. Most of the times I used it in ifs, fors and switches I ended up thinking it hardened readability of my code (perhaps because of placement, but I do not think alternatives made it more readable) and so it was my decision to stop using where whenever possible in my code. Since Erica's performance test pointed out using guard is nearly as fast as using where and the core team is removing wheres from ifs, I think the ones in fors could go next.

--
Károly
@lorentey

[trs (Thorsten Seitz)]

There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica, I have do not recall hearing that many voices saying that 'where' is confusing.

Shawn Erickson wrote this to the list just yesterday:

"I support your position on the use of where and while/when being confusing in the loop statement. I (and I know others) have for example used where in a loop statement mistakenly thinking it would terminate the loop early but of course learned that it basically filters what causes the loop body to be executed. After the fact that made sense to me but it didn't click at first."

Yes, there's was maybe even less voices stating that it is not confusing, but which group is more vocal?

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for .. in .., continue if not matching).

I'm glad that you find it very clear. I do as well. That does not mean it is clear to everyone.

So all these people never had contact with SQL?

-Thorsten

···

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

On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> a écrit :

I know there's a linguist on the list, maybe he could comment on whether or not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first, that it warrant removal from the language.

It is a very bad sign if something is confusing at first, especially to a significant proportion of users. It's true by definition that once you have mastered something you are no longer confused by it.

As has been stated on this list, education is a valid and important consideration for Swift. If something is confusing rather than difficult (and the *concept* of filtering a list is not at all a difficult concept), and if the same underlying concept can already be invoked in alternative and equivalent ways that are not confusing, then it's a no-brainer that the confusing thing is harmful to the language and should be removed on that basis alone.

By analogy, Chinese and Japanese share difficult writing systems. Yet many people use those languages daily without difficulty. Does that mean there's not a problem? Far from it: in fact, you'll find that many intelligent people have devoted their life's work to mitigating the issue. Both Chinese and Japanese underwent a round of simplification in the 20th century. Think about it: real languages used for daily life by a significant fraction of the world's population were revamped for the purpose of increasing accessibility to new learners.

The by-value/by-reference is well define, but can be confusing at first. Same goes for eager/lazy processing, or escaping vs non-escaping closure, or even the difference between closure and function. But no one suggest to remove them.

Value types vs. reference types is a concept (and a moderately advanced one), eager vs. lazy processing is a concept (and a moderately advanced one), and closures are a concept (and definitely an advanced one).

Filtering a collection is a concept as well, and no one is suggesting its removal. We are proposing to simplify and rationalize the syntax by which filtering is invoked. If there were a way to dramatically simplify the syntax surrounding value types and reference types so as to diminish confusion, you can absolutely guarantee that there would be proposals to change the syntax. If I could think of one tomorrow, you'd see a thread tomorrow about it. I don't think I'm that smart though.

Dany

In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use `where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose other than an academic consistency.

On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <swift-evolution@swift.org> wrote:
        As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is the perfect example of this. No one will find the use of “where” in loops confusing, aside from those who will wonder why it was removed from if statements. There is no misleading behavior or confusing syntax here. This is just consistency for consistency’s sake. Once this proposal is done, then another will be made to remove “where” from another place in the language. Then another and another until it’s gone completely and a very useful part of the language is removed in the name of consistency. Which really just comes down to “where” isn’t used here, so it can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
>> See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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)]

There have been, in previous threads, several examples given where users
of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica,
I have do not recall hearing that many voices saying that 'where' is
confusing.

Shawn Erickson wrote this to the list just yesterday:

"I support your position on the use of where and while/when being
confusing in the loop statement. I (and I know others) have for example
used where in a loop statement mistakenly thinking it would terminate the
loop early but of course learned that it basically filters what causes the
loop body to be executed. After the fact that made sense to me but it
didn't click at first."

Couldn't we find examples of anyone being confused at any syntax?
Especially with an unfamiliar construct in a new language.

If people find the new proposed syntax confusing, do we pull that too? At
what point do we stop?

That is why I favored (1) removal of the confusing syntax altogether; and
(2) this proposal, which involves aligning the confusing syntax with an
existing syntax. In short, no new syntax to get confused about.

Yes, there's was maybe even less voices stating that it is not confusing,

but which group is more vocal?

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for ..
in .., continue if not matching).

I'm glad that you find it very clear. I do as well. That does not mean it
is clear to everyone.

I still have yet to see widespread confusion of this. A few people
learning swift here or there, but once they learn the syntax...do they
still find it 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?

I expect some concrete data on stuff like this...especially with proposed

syntax changes.

Without concrete examples, what would stop one from coming in here and
waving their hands around to push *what they like* through?

Here's what's not handwavy:

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

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

* There are other ways to break from a loop or continue to the next
iteration without performance penalty. Nearly all of these serve more
general purposes than a `where` clause. Some of these (such as `if` or
`guard`) would already be familiar to a new user before they encounter
loops, assuming a typical order for learning a programming language. Many
of these (such as filtering methods on collections, or simply `if`) would
be familiar to a user of another C-family language. Therefore, the `where`
clause provides no independent utility, is not more discoverable than its
alternatives, and is not required for progressive disclosure of an
important facility to a learner (i.e. a simplified syntax for those who may
not be ready for the advanced concepts needed to use a more fully-featured
alternative).

Conclusion: the `where` clause is unprecedented, unintuitive, provides no
independent utility, is not more discoverable than alternatives, and is not
required for pedagogical reasons; however, it has been used incorrectly by
at least some users. Therefore, it is harmful and ought to be removed or
reformed.

I know there's a linguist on the list, maybe he could comment on whether or

not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first,
that it warrant removal from the language.

It is a very bad sign if something is confusing at first, especially to a
significant proportion of users. It's true by definition that once you have
mastered something you are no longer confused by it.

Again, where is this significant proportion of users? I don't mean to
hound you on this, but I am genuinely curious where this is all coming from.

We were talking about the hypothetical something here and what the bar
should be for removal from the language. My response is that being
confusing at first sight *is* a legitimate consideration for removal from
the language. If something turns out to be a confusing way to describe a
straightforward concept, then the more widespread the confusion, the more
urgent its removal.

The burden of evidence is on the proposers of these ideas.

As has been stated on this list, education is a valid and important
consideration for Swift. If something is confusing rather than difficult
(and the *concept* of filtering a list is not at all a difficult concept),
and if the same underlying concept can already be invoked in alternative
and equivalent ways that are not confusing, then it's a no-brainer that the
confusing thing is harmful to the language and should be removed on that
basis alone.

What is clear to one person may be confusing to another. There is no
perfect syntax that will not make it confusing for some users.

----

I really think it is important to come armed with more information with
these proposals. It's easy to say a significant proportion of people are
confused but it would make me much more comfortable to see this data to
back it up.

What if we are spinning our wheels for no reason on a feature that *most*
don't find confusing? What if we make a bigger proportion of those who did
understand it more confused now?

The point here is that this is not a slippery slope. If `where` offered
independent utility, then some confusion alone probably wouldn't be enough
to justify removal, though it may justify some consideration for change.
However, as the extensive discussion has shown, there is nothing `where`
can do that something else can't do better. I know you like it for style,
but that's not sufficient grounds for keeping something confusing, IMO.

···

On Fri, Jun 10, 2016 at 12:48 AM, Brandon Knope <bknope@me.com> wrote:

On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> a écrit :

Brandon

By analogy, Chinese and Japanese share difficult writing systems. Yet many
people use those languages daily without difficulty. Does that mean there's
not a problem? Far from it: in fact, you'll find that many intelligent
people have devoted their life's work to mitigating the issue. Both Chinese
and Japanese underwent a round of simplification in the 20th century. Think
about it: real languages used for daily life by a significant fraction of
the world's population were revamped for the purpose of increasing
accessibility to new learners.

The by-value/by-reference is well define, but can be confusing at first.

Same goes for eager/lazy processing, or escaping vs non-escaping closure,
or even the difference between closure and function. But no one suggest to
remove them.

Value types vs. reference types is a concept (and a moderately advanced
one), eager vs. lazy processing is a concept (and a moderately advanced
one), and closures are a concept (and definitely an advanced one).

Filtering a collection is a concept as well, and no one is suggesting its
removal. We are proposing to simplify and rationalize the syntax by which
filtering is invoked. If there were a way to dramatically simplify the
syntax surrounding value types and reference types so as to diminish
confusion, you can absolutely guarantee that there would be proposals to
change the syntax. If I could think of one tomorrow, you'd see a thread
tomorrow about it. I don't think I'm that smart though.

Dany

In fact, the first of these proposals began with a question: how does one
write arbitrary Boolean assertions after a let binding? The answer (use
`where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose
other than an academic consistency.
On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution < >> swift-evolution@swift.org> wrote:

        As time goes on, I’m feeling more and more that these
consistency proposals are sorely misguided. Frankly, unless the syntax is
confusing or misleading, even once the developer has learned the guiding
principles of Swift, consistency is not a good argument for change. This
proposal is the perfect example of this. No one will find the use of
“where” in loops confusing, aside from those who will wonder why it was
removed from if statements. There is no misleading behavior or confusing
syntax here. This is just consistency for consistency’s sake. Once this
proposal is done, then another will be made to remove “where” from another
place in the language. Then another and another until it’s gone completely
and a very useful part of the language is removed in the name of
consistency. Which really just comes down to “where” isn’t used here, so it
can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution < >>> swift-evolution@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe < >>> charlie@charliemonroe.net> wrote:
>> See my latest post - included results with -Ofast. But still, using
filter and lazy.filter is 10+% slower, which were the suggested
alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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

[Dany_St-Amant]

An example here would have help... I had trouble visualizing the 'where' with 'while'. A quick example I was able to conjure is:

var array = [9,8,7,6,5,4,3,2,1]
while let x = are.popLast() where x < 5 { print(x) }
print(array)

What? 'array' is not empty at the end. I admit, I was surprised by the result at first. The confusion here is not that 'where' in 'for' behave like 'continue' and 'where' in 'while' act like a 'break', as the later doesn't conceptually exist. The later concept is using 'where' as a conditional binding in a 'while' causes a failure of the bind and thus a 'break' out of the loop. With the acceptance of the revised SE-0099, the 'while' can no longer appear to be using 'where', thus removing this confusion.

Dany

···

Le 10 juin 2016 à 02:25, Xiaodi Wu <xiaodi.wu@gmail.com> a écrit :

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

[Karl]

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

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!

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

I didn’t even know while loops supported “where”. I can’t even imagine what that would look like, or how I would reason about one if I saw one. I Googled around a little bit and couldn’t find any examples. If they exist, sure, go ahead, get rid of them. Nobody will miss them. It definitely makes sense on ‘for’, though. Lots and lots of people will miss that; it’s a pretty well-known feature.

Also, after everything you said, it’s still not unintuitive. That is not how languages work at all. Languages spoken by human beings are always ambiguous to some extent, and we use context to determine which meaning is correct:

(Quote from https://research.googleblog.com/2016/05/announcing-syntaxnet-worlds-most.html\)

One of the main problems that makes parsing so challenging is that human languages show remarkable levels of ambiguity. It is not uncommon for moderate length sentences - say 20 or 30 words in length - to have hundreds, thousands, or even tens of thousands of possible syntactic structures. A natural language parser must somehow search through all of these alternatives, and find the most plausible structure given the context. As a very simple example, the sentence "Alice drove down the street in her car" has at least two possible dependency parses:

The first corresponds to the (correct) interpretation where Alice is driving in her car; the second corresponds to the (absurd, but possible) interpretation where the street is located in her car. The ambiguity arises because the preposition “in" can either modify drove or street; this example is an instance of what is called prepositional phrase attachment ambiguity.

Even algebra is not completely unambiguous - you need to use BODMAS rules to disambiguate potential meanings.
It’s this context which I think you’re missing when zooming in at the word “where”:

- The context that this is a variation of a ‘for x in y’ loop. We know that it loops through every item in ‘y' and assigns it ‘x’. It is literally Section 2 of the 'Swift Tour' - you learn how to assign a variable, and then you learn about the “for x in y” loop. Everybody should recognise it.
- The context that ‘x’ is the subject, so ‘where’ is clearly a condition for x to fulfill
- The context that ‘where’ occurs after ‘in’, so it follows the order in which its written: ‘for every x in y, where such-and-such is true, do …”
- The “for x in y” loop is a data-driven loop. It doesn’t even have a loop index. It is not like a C for loop and you shouldn’t expect to reason about it that way.

* There are other ways to break from a loop or continue to the next iteration without performance penalty. Nearly all of these serve more general purposes than a `where` clause. Some of these (such as `if` or `guard`) would already be familiar to a new user before they encounter loops, assuming a typical order for learning a programming language. Many of these (such as filtering methods on collections, or simply `if`) would be familiar to a user of another C-family language. Therefore, the `where` clause provides no independent utility, is not more discoverable than its alternatives, and is not required for progressive disclosure of an important facility to a learner (i.e. a simplified syntax for those who may not be ready for the advanced concepts needed to use a more fully-featured alternative).

You say the points in favour of removal are not handwavey, but I’m still not convinced. “There are other ways to go to where this shortcut goes” is not reasoning. And I’d definitely argue that it is more discoverable than the ‘guard’ statement. The guard statement is stone-dead last at the end of a massive “Control-Flow” page. I would guess that most first-time readers skip those topics for later.

The point here is that this is not a slippery slope. If `where` offered independent utility, then some confusion alone probably wouldn't be enough to justify removal, though it may justify some consideration for change. However, as the extensive discussion has shown, there is nothing `where` can do that something else can't do better. I know you like it for style, but that's not sufficient grounds for keeping something confusing, IMO.

It’s more readable. It does that better. The tests also seem to show that (bizarrely) it’s also slightly faster than the alternatives.

Karl

···

On 10 Jun 2016, at 08:25, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, Jun 10, 2016 at 12:48 AM, Brandon Knope <bknope@me.com <mailto:bknope@me.com>> wrote:

On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls@icloud.com <mailto:dsa.mls@icloud.com>> wrote:

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica, I have do not recall hearing that many voices saying that 'where' is confusing.

Shawn Erickson wrote this to the list just yesterday:

"I support your position on the use of where and while/when being confusing in the loop statement. I (and I know others) have for example used where in a loop statement mistakenly thinking it would terminate the loop early but of course learned that it basically filters what causes the loop body to be executed. After the fact that made sense to me but it didn't click at first."

Couldn't we find examples of anyone being confused at any syntax? Especially with an unfamiliar construct in a new language.

If people find the new proposed syntax confusing, do we pull that too? At what point do we stop?

That is why I favored (1) removal of the confusing syntax altogether; and (2) this proposal, which involves aligning the confusing syntax with an existing syntax. In short, no new syntax to get confused about.

Yes, there's was maybe even less voices stating that it is not confusing, but which group is more vocal?

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for .. in .., continue if not matching).

I'm glad that you find it very clear. I do as well. That does not mean it is clear to everyone.

I still have yet to see widespread confusion of this. A few people learning swift here or there, but once they learn the syntax...do they still find it confusing?

I expect some concrete data on stuff like this...especially with proposed syntax changes.

Without concrete examples, what would stop one from coming in here and waving their hands around to push *what they like* through?

Here's what's not handwavy:

Conclusion: the `where` clause is unprecedented, unintuitive, provides no independent utility, is not more discoverable than alternatives, and is not required for pedagogical reasons; however, it has been used incorrectly by at least some users. Therefore, it is harmful and ought to be removed or reformed.

I know there's a linguist on the list, maybe he could comment on whether or not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first, that it warrant removal from the language.

It is a very bad sign if something is confusing at first, especially to a significant proportion of users. It's true by definition that once you have mastered something you are no longer confused by it.

Again, where is this significant proportion of users? I don't mean to hound you on this, but I am genuinely curious where this is all coming from.

We were talking about the hypothetical something here and what the bar should be for removal from the language. My response is that being confusing at first sight *is* a legitimate consideration for removal from the language. If something turns out to be a confusing way to describe a straightforward concept, then the more widespread the confusion, the more urgent its removal.

The burden of evidence is on the proposers of these ideas.

As has been stated on this list, education is a valid and important consideration for Swift. If something is confusing rather than difficult (and the *concept* of filtering a list is not at all a difficult concept), and if the same underlying concept can already be invoked in alternative and equivalent ways that are not confusing, then it's a no-brainer that the confusing thing is harmful to the language and should be removed on that basis alone.

What is clear to one person may be confusing to another. There is no perfect syntax that will not make it confusing for some users.

----

I really think it is important to come armed with more information with these proposals. It's easy to say a significant proportion of people are confused but it would make me much more comfortable to see this data to back it up.

What if we are spinning our wheels for no reason on a feature that *most* don't find confusing? What if we make a bigger proportion of those who did understand it more confused now?

Brandon

By analogy, Chinese and Japanese share difficult writing systems. Yet many people use those languages daily without difficulty. Does that mean there's not a problem? Far from it: in fact, you'll find that many intelligent people have devoted their life's work to mitigating the issue. Both Chinese and Japanese underwent a round of simplification in the 20th century. Think about it: real languages used for daily life by a significant fraction of the world's population were revamped for the purpose of increasing accessibility to new learners.

The by-value/by-reference is well define, but can be confusing at first. Same goes for eager/lazy processing, or escaping vs non-escaping closure, or even the difference between closure and function. But no one suggest to remove them.

Value types vs. reference types is a concept (and a moderately advanced one), eager vs. lazy processing is a concept (and a moderately advanced one), and closures are a concept (and definitely an advanced one).

Filtering a collection is a concept as well, and no one is suggesting its removal. We are proposing to simplify and rationalize the syntax by which filtering is invoked. If there were a way to dramatically simplify the syntax surrounding value types and reference types so as to diminish confusion, you can absolutely guarantee that there would be proposals to change the syntax. If I could think of one tomorrow, you'd see a thread tomorrow about it. I don't think I'm that smart though.

Dany

In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use `where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose other than an academic consistency.
On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
        As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is the perfect example of this. No one will find the use of “where” in loops confusing, aside from those who will wonder why it was removed from if statements. There is no misleading behavior or confusing syntax here. This is just consistency for consistency’s sake. Once this proposal is done, then another will be made to remove “where” from another place in the language. Then another and another until it’s gone completely and a very useful part of the language is removed in the name of consistency. Which really just comes down to “where” isn’t used here, so it can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net <mailto:charlie@charliemonroe.net>> wrote:
>> See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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

[Haravikk3 (Haravikk)]

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

Swift may have some similarities with C, but the last thing anyone should want is for it to be bound to C as a language. Besides, the purpose of a for in loop is to iterate over elements in a sequence, so filtering is very much a useful thing to do so it’s hardly unprecedented, and it’s also a fairly common thing to want to do.

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

* There are other ways to break from a loop or continue to the next iteration without performance penalty. Nearly all of these serve more general purposes than a `where` clause.

This isn’t really an argument against the where clause; the where clause is useful for common, simple cases, so it’s not surprising if more complex/unusual cases can’t (or can’t easily) be handled by it. This is for the simple cases where this isn’t an issue.

Some of these (such as `if` or `guard`) would already be familiar to a new user before they encounter loops, assuming a typical order for learning a programming language. Many of these (such as filtering methods on collections, or simply `if`) would be familiar to a user of another C-family language. Therefore, the `where` clause provides no independent utility, is not more discoverable than its alternatives, and is not required for progressive disclosure of an important facility to a learner (i.e. a simplified syntax for those who may not be ready for the advanced concepts needed to use a more fully-featured alternative).

Simplification isn’t just for the new users; all you need to know with where is that it’s a shorthand for guard X else { continue }, for many people this is intuitive enough, but if there are enough for whom it isn’t then again that’s an argument to tweak it to be more clear about what it does, rather than remove it entirely.

The independent utility that it offers is being able to avoid if/guard boilerplate at the start of your loop, but instead putting it on the same line; in simple cases this can be nice and neat.

it has been used incorrectly by at least some users.

Every feature in every language "has been used incorrectly by at least some users", should we just drop all programming languages? It’s not as if users can’t make mistakes while using an inline if/guard condition. Again, this an argument that the meaning isn’t implicit enough, which is just as well served by tweaking the syntax than removing it.

···

On 10 Jun 2016, at 07:25, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

[L_Mihalkovic]

using WHERE in this context had a flair of C# Linq, only not coming even close to what can be done with Linq… I think pulling out WHERE from the places where advanced users might make that connection is a wise decision that will avoid people calling it a really-poor-man’s replacement for Linq. With a bit of luck, a truly smart .WHERE (yes '.’) might one day resurface (even under a different name), but this type with REAL horse power.

just a thought.

···

On Jun 10, 2016, at 8:25 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Fri, Jun 10, 2016 at 12:48 AM, Brandon Knope <bknope@me.com <mailto:bknope@me.com>> wrote:

On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls@icloud.com <mailto:dsa.mls@icloud.com>> wrote:

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica, I have do not recall hearing that many voices saying that 'where' is confusing.

Shawn Erickson wrote this to the list just yesterday:

"I support your position on the use of where and while/when being confusing in the loop statement. I (and I know others) have for example used where in a loop statement mistakenly thinking it would terminate the loop early but of course learned that it basically filters what causes the loop body to be executed. After the fact that made sense to me but it didn't click at first."

Couldn't we find examples of anyone being confused at any syntax? Especially with an unfamiliar construct in a new language.

If people find the new proposed syntax confusing, do we pull that too? At what point do we stop?

That is why I favored (1) removal of the confusing syntax altogether; and (2) this proposal, which involves aligning the confusing syntax with an existing syntax. In short, no new syntax to get confused about.

Yes, there's was maybe even less voices stating that it is not confusing, but which group is more vocal?

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for .. in .., continue if not matching).

I'm glad that you find it very clear. I do as well. That does not mean it is clear to everyone.

I still have yet to see widespread confusion of this. A few people learning swift here or there, but once they learn the syntax...do they still find it 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?

I expect some concrete data on stuff like this...especially with proposed syntax changes.

Without concrete examples, what would stop one from coming in here and waving their hands around to push *what they like* through?

Here's what's not handwavy:

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

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

* There are other ways to break from a loop or continue to the next iteration without performance penalty. Nearly all of these serve more general purposes than a `where` clause. Some of these (such as `if` or `guard`) would already be familiar to a new user before they encounter loops, assuming a typical order for learning a programming language. Many of these (such as filtering methods on collections, or simply `if`) would be familiar to a user of another C-family language. Therefore, the `where` clause provides no independent utility, is not more discoverable than its alternatives, and is not required for progressive disclosure of an important facility to a learner (i.e. a simplified syntax for those who may not be ready for the advanced concepts needed to use a more fully-featured alternative).

Conclusion: the `where` clause is unprecedented, unintuitive, provides no independent utility, is not more discoverable than alternatives, and is not required for pedagogical reasons; however, it has been used incorrectly by at least some users. Therefore, it is harmful and ought to be removed or reformed.

I know there's a linguist on the list, maybe he could comment on whether or not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first, that it warrant removal from the language.

It is a very bad sign if something is confusing at first, especially to a significant proportion of users. It's true by definition that once you have mastered something you are no longer confused by it.

Again, where is this significant proportion of users? I don't mean to hound you on this, but I am genuinely curious where this is all coming from.

We were talking about the hypothetical something here and what the bar should be for removal from the language. My response is that being confusing at first sight *is* a legitimate consideration for removal from the language. If something turns out to be a confusing way to describe a straightforward concept, then the more widespread the confusion, the more urgent its removal.

The burden of evidence is on the proposers of these ideas.

As has been stated on this list, education is a valid and important consideration for Swift. If something is confusing rather than difficult (and the *concept* of filtering a list is not at all a difficult concept), and if the same underlying concept can already be invoked in alternative and equivalent ways that are not confusing, then it's a no-brainer that the confusing thing is harmful to the language and should be removed on that basis alone.

What is clear to one person may be confusing to another. There is no perfect syntax that will not make it confusing for some users.

----

I really think it is important to come armed with more information with these proposals. It's easy to say a significant proportion of people are confused but it would make me much more comfortable to see this data to back it up.

What if we are spinning our wheels for no reason on a feature that *most* don't find confusing? What if we make a bigger proportion of those who did understand it more confused now?

The point here is that this is not a slippery slope. If `where` offered independent utility, then some confusion alone probably wouldn't be enough to justify removal, though it may justify some consideration for change. However, as the extensive discussion has shown, there is nothing `where` can do that something else can't do better. I know you like it for style, but that's not sufficient grounds for keeping something confusing, IMO.

Brandon

By analogy, Chinese and Japanese share difficult writing systems. Yet many people use those languages daily without difficulty. Does that mean there's not a problem? Far from it: in fact, you'll find that many intelligent people have devoted their life's work to mitigating the issue. Both Chinese and Japanese underwent a round of simplification in the 20th century. Think about it: real languages used for daily life by a significant fraction of the world's population were revamped for the purpose of increasing accessibility to new learners.

The by-value/by-reference is well define, but can be confusing at first. Same goes for eager/lazy processing, or escaping vs non-escaping closure, or even the difference between closure and function. But no one suggest to remove them.

Value types vs. reference types is a concept (and a moderately advanced one), eager vs. lazy processing is a concept (and a moderately advanced one), and closures are a concept (and definitely an advanced one).

Filtering a collection is a concept as well, and no one is suggesting its removal. We are proposing to simplify and rationalize the syntax by which filtering is invoked. If there were a way to dramatically simplify the syntax surrounding value types and reference types so as to diminish confusion, you can absolutely guarantee that there would be proposals to change the syntax. If I could think of one tomorrow, you'd see a thread tomorrow about it. I don't think I'm that smart though.

Dany

In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use `where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose other than an academic consistency.
On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
        As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is the perfect example of this. No one will find the use of “where” in loops confusing, aside from those who will wonder why it was removed from if statements. There is no misleading behavior or confusing syntax here. This is just consistency for consistency’s sake. Once this proposal is done, then another will be made to remove “where” from another place in the language. Then another and another until it’s gone completely and a very useful part of the language is removed in the name of consistency. Which really just comes down to “where” isn’t used here, so it can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net <mailto:charlie@charliemonroe.net>> wrote:
>> See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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)]

There have been, in previous threads, several examples given where users
of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica,
I have do not recall hearing that many voices saying that 'where' is
confusing.

Shawn Erickson wrote this to the list just yesterday:

"I support your position on the use of where and while/when being
confusing in the loop statement. I (and I know others) have for example
used where in a loop statement mistakenly thinking it would terminate the
loop early but of course learned that it basically filters what causes the
loop body to be executed. After the fact that made sense to me but it
didn't click at first."

Yes, there's was maybe even less voices stating that it is not confusing,
but which group is more vocal?

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for ..
in .., continue if not matching).

I'm glad that you find it very clear. I do as well. That does not mean it
is clear to everyone.

So all these people never had contact with SQL?

What do you mean by this comment? Do you expect users of Swift to arrive at
the language already knowing SQL?

···

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

Am 10.06.2016 um 07:08 schrieb Xiaodi Wu via swift-evolution < > swift-evolution@swift.org>:
On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> a écrit :

-Thorsten

I know there's a linguist on the list, maybe he could comment on whether
or not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first,
that it warrant removal from the language.

It is a very bad sign if something is confusing at first, especially to a
significant proportion of users. It's true by definition that once you have
mastered something you are no longer confused by it.

As has been stated on this list, education is a valid and important
consideration for Swift. If something is confusing rather than difficult
(and the *concept* of filtering a list is not at all a difficult concept),
and if the same underlying concept can already be invoked in alternative
and equivalent ways that are not confusing, then it's a no-brainer that the
confusing thing is harmful to the language and should be removed on that
basis alone.

By analogy, Chinese and Japanese share difficult writing systems. Yet many
people use those languages daily without difficulty. Does that mean there's
not a problem? Far from it: in fact, you'll find that many intelligent
people have devoted their life's work to mitigating the issue. Both Chinese
and Japanese underwent a round of simplification in the 20th century. Think
about it: real languages used for daily life by a significant fraction of
the world's population were revamped for the purpose of increasing
accessibility to new learners.

The by-value/by-reference is well define, but can be confusing at first.

Same goes for eager/lazy processing, or escaping vs non-escaping closure,
or even the difference between closure and function. But no one suggest to
remove them.

Value types vs. reference types is a concept (and a moderately advanced
one), eager vs. lazy processing is a concept (and a moderately advanced
one), and closures are a concept (and definitely an advanced one).

Filtering a collection is a concept as well, and no one is suggesting its
removal. We are proposing to simplify and rationalize the syntax by which
filtering is invoked. If there were a way to dramatically simplify the
syntax surrounding value types and reference types so as to diminish
confusion, you can absolutely guarantee that there would be proposals to
change the syntax. If I could think of one tomorrow, you'd see a thread
tomorrow about it. I don't think I'm that smart though.

Dany

In fact, the first of these proposals began with a question: how does one
write arbitrary Boolean assertions after a let binding? The answer (use
`where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose
other than an academic consistency.
On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution < >> swift-evolution@swift.org> wrote:

        As time goes on, I’m feeling more and more that these
consistency proposals are sorely misguided. Frankly, unless the syntax is
confusing or misleading, even once the developer has learned the guiding
principles of Swift, consistency is not a good argument for change. This
proposal is the perfect example of this. No one will find the use of
“where” in loops confusing, aside from those who will wonder why it was
removed from if statements. There is no misleading behavior or confusing
syntax here. This is just consistency for consistency’s sake. Once this
proposal is done, then another will be made to remove “where” from another
place in the language. Then another and another until it’s gone completely
and a very useful part of the language is removed in the name of
consistency. Which really just comes down to “where” isn’t used here, so it
can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution < >>> swift-evolution@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe < >>> charlie@charliemonroe.net> wrote:
>> See my latest post - included results with -Ofast. But still, using
filter and lazy.filter is 10+% slower, which were the suggested
alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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

[trs (Thorsten Seitz)]

+1

-Thorsten

···

Am 10.06.2016 um 07:48 schrieb Brandon Knope via swift-evolution <swift-evolution@swift.org>:

On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> a écrit :

There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica, I have do not recall hearing that many voices saying that 'where' is confusing.

Shawn Erickson wrote this to the list just yesterday:

"I support your position on the use of where and while/when being confusing in the loop statement. I (and I know others) have for example used where in a loop statement mistakenly thinking it would terminate the loop early but of course learned that it basically filters what causes the loop body to be executed. After the fact that made sense to me but it didn't click at first."

Couldn't we find examples of anyone being confused at any syntax? Especially with an unfamiliar construct in a new language.

If people find the new proposed syntax confusing, do we pull that too? At what point do we stop?

Yes, there's was maybe even less voices stating that it is not confusing, but which group is more vocal?

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for .. in .., continue if not matching).

I'm glad that you find it very clear. I do as well. That does not mean it is clear to everyone.

I still have yet to see widespread confusion of this. A few people learning swift here or there, but once they learn the syntax...do they still find it confusing?

I expect some concrete data on stuff like this...especially with proposed syntax changes.

Without concrete examples, what would stop one from coming in here and waving their hands around to push *what they like* through?

I know there's a linguist on the list, maybe he could comment on whether or not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first, that it warrant removal from the language.

It is a very bad sign if something is confusing at first, especially to a significant proportion of users. It's true by definition that once you have mastered something you are no longer confused by it.

Again, where is this significant proportion of users? I don't mean to hound you on this, but I am genuinely curious where this is all coming from.

The burden of evidence is on the proposers of these ideas.

As has been stated on this list, education is a valid and important consideration for Swift. If something is confusing rather than difficult (and the *concept* of filtering a list is not at all a difficult concept), and if the same underlying concept can already be invoked in alternative and equivalent ways that are not confusing, then it's a no-brainer that the confusing thing is harmful to the language and should be removed on that basis alone.

What is clear to one person may be confusing to another. There is no perfect syntax that will not make it confusing for some users.

----

I really think it is important to come armed with more information with these proposals. It's easy to say a significant proportion of people are confused but it would make me much more comfortable to see this data to back it up.

What if we are spinning our wheels for no reason on a feature that *most* don't find confusing? What if we make a bigger proportion of those who did understand it more confused now?

Brandon

By analogy, Chinese and Japanese share difficult writing systems. Yet many people use those languages daily without difficulty. Does that mean there's not a problem? Far from it: in fact, you'll find that many intelligent people have devoted their life's work to mitigating the issue. Both Chinese and Japanese underwent a round of simplification in the 20th century. Think about it: real languages used for daily life by a significant fraction of the world's population were revamped for the purpose of increasing accessibility to new learners.

The by-value/by-reference is well define, but can be confusing at first. Same goes for eager/lazy processing, or escaping vs non-escaping closure, or even the difference between closure and function. But no one suggest to remove them.

Value types vs. reference types is a concept (and a moderately advanced one), eager vs. lazy processing is a concept (and a moderately advanced one), and closures are a concept (and definitely an advanced one).

Filtering a collection is a concept as well, and no one is suggesting its removal. We are proposing to simplify and rationalize the syntax by which filtering is invoked. If there were a way to dramatically simplify the syntax surrounding value types and reference types so as to diminish confusion, you can absolutely guarantee that there would be proposals to change the syntax. If I could think of one tomorrow, you'd see a thread tomorrow about it. I don't think I'm that smart though.

Dany

In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use `where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose other than an academic consistency.

On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <swift-evolution@swift.org> wrote:
        As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is the perfect example of this. No one will find the use of “where” in loops confusing, aside from those who will wonder why it was removed from if statements. There is no misleading behavior or confusing syntax here. This is just consistency for consistency’s sake. Once this proposal is done, then another will be made to remove “where” from another place in the language. Then another and another until it’s gone completely and a very useful part of the language is removed in the name of consistency. Which really just comes down to “where” isn’t used here, so it can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
>> See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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

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

[trs (Thorsten Seitz)]

There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing.

Sorry Xiaodi, but beside you (on multiple instances), and recently Erica, I have do not recall hearing that many voices saying that 'where' is confusing.

Shawn Erickson wrote this to the list just yesterday:

"I support your position on the use of where and while/when being confusing in the loop statement. I (and I know others) have for example used where in a loop statement mistakenly thinking it would terminate the loop early but of course learned that it basically filters what causes the loop body to be executed. After the fact that made sense to me but it didn't click at first."

Yes, there's was maybe even less voices stating that it is not confusing, but which group is more vocal?

Maybe I have been recently corrupt by Solid SQL queries:
select * from PEOPLE_TABLE where AGE_FIELD = 100

Or by my (likely) broken English:
The places where I had the most fun

But, to me, where can only suggest some filtering (thus tag to a for .. in .., continue if not matching).

I'm glad that you find it very clear. I do as well. That does not mean it is clear to everyone.

So all these people never had contact with SQL?

What do you mean by this comment? Do you expect users of Swift to arrive at the language already knowing SQL?

Not as a requirement but as a probability.
I mean that it is likely that they already had contact with SQL (or C#) where `where` is used without the problems you insist being present in Swift.
I don't buy your argument that `where` in for-loops is confusing. It is perfectly aligned with its usage in mathematics or SQL.
That it is relatively little known is a deficiency in the documentation which would be easily fixed. I don't agree with your discoverability argument. When I wonder about the meaning of a keyword I'm going to have a look at the documentation. It might be old school to look it up myself instead of getting it presented by clicking on it but it isn't that difficult. When learning a new language I read the languages documentation. How would you know how to write a for-loop in Swift in the first place when you come from Java, say? How would you know to use "in" instead of ":"? Just RTFM and you will discover `where` right in there (if the documentation is fixed).

-Thorsten

···

Am 11.06.2016 um 21:50 schrieb Xiaodi Wu <xiaodi.wu@gmail.com>:

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

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

On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> a écrit :

-Thorsten

I know there's a linguist on the list, maybe he could comment on whether or not using 'where' as a filter is proper or an abomination.

I do not think that because something is confusing to some, or at first, that it warrant removal from the language.

It is a very bad sign if something is confusing at first, especially to a significant proportion of users. It's true by definition that once you have mastered something you are no longer confused by it.

As has been stated on this list, education is a valid and important consideration for Swift. If something is confusing rather than difficult (and the *concept* of filtering a list is not at all a difficult concept), and if the same underlying concept can already be invoked in alternative and equivalent ways that are not confusing, then it's a no-brainer that the confusing thing is harmful to the language and should be removed on that basis alone.

By analogy, Chinese and Japanese share difficult writing systems. Yet many people use those languages daily without difficulty. Does that mean there's not a problem? Far from it: in fact, you'll find that many intelligent people have devoted their life's work to mitigating the issue. Both Chinese and Japanese underwent a round of simplification in the 20th century. Think about it: real languages used for daily life by a significant fraction of the world's population were revamped for the purpose of increasing accessibility to new learners.

The by-value/by-reference is well define, but can be confusing at first. Same goes for eager/lazy processing, or escaping vs non-escaping closure, or even the difference between closure and function. But no one suggest to remove them.

Value types vs. reference types is a concept (and a moderately advanced one), eager vs. lazy processing is a concept (and a moderately advanced one), and closures are a concept (and definitely an advanced one).

Filtering a collection is a concept as well, and no one is suggesting its removal. We are proposing to simplify and rationalize the syntax by which filtering is invoked. If there were a way to dramatically simplify the syntax surrounding value types and reference types so as to diminish confusion, you can absolutely guarantee that there would be proposals to change the syntax. If I could think of one tomorrow, you'd see a thread tomorrow about it. I don't think I'm that smart though.

Dany

In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use `where`) was found to be misleading and confusing.

I think you're being unfair to say that these proposals have no purpose other than an academic consistency.

On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <swift-evolution@swift.org> wrote:
        As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is the perfect example of this. No one will find the use of “where” in loops confusing, aside from those who will wonder why it was removed from if statements. There is no misleading behavior or confusing syntax here. This is just consistency for consistency’s sake. Once this proposal is done, then another will be made to remove “where” from another place in the language. Then another and another until it’s gone completely and a very useful part of the language is removed in the name of consistency. Which really just comes down to “where” isn’t used here, so it can’t be used there anymore. It’s death by a thousand cuts.

Jon Shier

> On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:
>> See my latest post - included results with -Ofast. But still, using filter and lazy.filter is 10+% slower, which were the suggested alternatives to `where`.
>>
>>
>
> I need to correct this misapprehension.
> My suggested alternative to where was and remains `guard`.
>
> -- E
>
> _______________________________________________
> 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