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

[Vladimir.S via swift-evolution]

On 23.06.2016 0:21, Erica Sadun via swift-evolution wrote:



On Jun 14, 2016, at 8:16 PM, Xiaodi Wu via swift-evolution
> wrote:

As you will see from earlier messages, the confused user is both quite
real and *is* on this list. Nor, mind you, are pedagogical concerns to be
trivialized; they are serious concerns for the design of the language. On
what grounds do you assert that something is "not confusing at all" when
there has been testimony saying "it was confusing to me"?

Some of us on this list interact regularly with novice coders. I draw
upon these experiences here. Do you have some special insight you'd like
to share in that regard?
On Tue, Jun 14, 2016 at 20:57 Jon Akhtar > wrote:

How about the goal of it being a delightful language to program in. I
think that is getting lost in proposals like these. Optimizing for
some mythical new user, who really isn’t present on this list to give
an opinion seems like a false argument to make, and your technical
sophistication makes you a less qualified than most to say what is
and what isn’t confusing to new users because you haven’t been one in
a long time.

-1 Leve it in. It is perfectly simple as is. Not confusing at all.
There are far more confusing aspects to the language than this.

Cheers


Yet another case from a few minutes ago:


Sorry.. but.. And what? Suggest  to write simple SQL query, will 
he/she be confused by 'WHERE' there? If  didn't know *for sure* 
what does 'where' means, why he/she didn't check docs or just checked in 
playground/IBM Swift Sandbox?


You found one more user confused by 'where'. I can find N users that were 
not confused by it even first time he/she saw it in code. And can find M 
users confused by any other construction/element of Swift. I just don't 
think such 'cases' could be treated as information that proves anything.




rullie : hi, could someone walk me through
this http://pastie.org/10887040
[3:08pm] rullie : why is it that for loop through an lazy
infinite sequence does not terminate even with the where clause invovled?
[
[3:08pm] mikeash : "where" means "skip iterations when this
condition is not true"
[3:08pm] mikeash : it doesn't mean "halt the loop when this
is not true"
[3:08pm] rullie : oh whoa.. ok
[3:09pm] mikeash : it can't know that you'll never see
another value < 100, so  it keeps on going
[3:09pm] rullie : ok, i completely misunderstood the where
clause then
[3:10pm] mikeash : I can see how it might look like it does
that
[3:10pm] rullie : is there a syntax that achieves what i
want to do without having to have a if-break in the loop?

-- E
p.s. Posted with permission from both participants



___
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

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

[Brandon Knope via swift-evolution]

Isn't this more caused by confusion about how infinite sequences work?

The prefix one is no longer an infinite sequence. The second one still is. The 
second one will always infinite loop unless you break

Brandon

Sent from my iPad

> On Jun 22, 2016, at 5:28 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 14, 2016, at 8:16 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> As you will see from earlier messages, the confused user is both quite real 
>> and *is* on this list. Nor, mind you, are pedagogical concerns to be 
>> trivialized; they are serious concerns for the design of the language. On 
>> what grounds do you assert that something is "not confusing at all" when 
>> there has been testimony saying "it was confusing to me"?
>> 
>> Some of us on this list interact regularly with novice coders. I draw upon 
>> these experiences here. Do you have some special insight you'd like to share 
>> in that regard?
>>> On Tue, Jun 14, 2016 at 20:57 Jon Akhtar  wrote:
>>> How about the goal of it being a delightful language to program in. I think 
>>> that is getting lost in proposals like these. Optimizing for some mythical 
>>> new user, who really isn’t present on this list to give an opinion seems 
>>> like a false argument to make, and your technical sophistication makes you 
>>> a less qualified than most to say what is and what isn’t confusing to new 
>>> users because you haven’t been one in a long time.
>>> 
>>> -1 Leve it in. It is perfectly simple as is. Not confusing at all. There 
>>> are far more confusing aspects to the language than this.
>>> 
>>> Cheers
> 
> Yet another case from a few minutes ago:
> 
> [3:08pm] rullie: hi, could someone walk me through this 
> http://pastie.org/10887040
> [3:08pm] rullie: why is it that for loop through an lazy infinite sequence 
> does not terminate even with the where clause invovled?
> [3:08pm] mikeash: "where" means "skip iterations when this condition is not 
> true"
> [3:08pm] mikeash: it doesn't mean "halt the loop when this is not true"
> [3:08pm] rullie: oh whoa.. ok
> [3:09pm] mikeash: it can't know that you'll never see another value < 100, so 
> it keeps on going
> [3:09pm] rullie: ok, i completely misunderstood the where clause then
> [3:10pm] mikeash: I can see how it might look like it does that
> [3:10pm] rullie: is there a syntax that achieves what i want to do without 
> having to have a if-break in the loop?
> 
> 
> -- E
> p.s. Posted with permission from both participants
> 
> ___
> 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

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

[Erica Sadun via swift-evolution]

> On Jun 14, 2016, at 8:16 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
> As you will see from earlier messages, the confused user is both quite real 
> and *is* on this list. Nor, mind you, are pedagogical concerns to be 
> trivialized; they are serious concerns for the design of the language. On 
> what grounds do you assert that something is "not confusing at all" when 
> there has been testimony saying "it was confusing to me"?
> 
> Some of us on this list interact regularly with novice coders. I draw upon 
> these experiences here. Do you have some special insight you'd like to share 
> in that regard?
> On Tue, Jun 14, 2016 at 20:57 Jon Akhtar  > wrote:
> How about the goal of it being a delightful language to program in. I think 
> that is getting lost in proposals like these. Optimizing for some mythical 
> new user, who really isn’t present on this list to give an opinion seems like 
> a false argument to make, and your technical sophistication makes you a less 
> qualified than most to say what is and what isn’t confusing to new users 
> because you haven’t been one in a long time.
> 
> -1 Leve it in. It is perfectly simple as is. Not confusing at all. There are 
> far more confusing aspects to the language than this.
> 
> Cheers

Yet another case from a few minutes ago:

[3:08pm] rullie: hi, could someone walk me through this 
http://pastie.org/10887040
[3:08pm] rullie: why is it that for loop through an lazy infinite sequence does 
not terminate even with the where clause invovled?
[3:08pm] mikeash: "where" means "skip iterations when this condition is not 
true"
[3:08pm] mikeash: it doesn't mean "halt the loop when this is not true"
[3:08pm] rullie: oh whoa.. ok
[3:09pm] mikeash: it can't know that you'll never see another value < 100, so 
it keeps on going
[3:09pm] rullie: ok, i completely misunderstood the where clause then
[3:10pm] mikeash: I can see how it might look like it does that
[3:10pm] rullie: is there a syntax that achieves what i want to do without 
having to have a if-break in the loop?


-- E
p.s. Posted with permission from both participants

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

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

[Erica Sadun via swift-evolution]

> On Jun 14, 2016, at 8:16 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> As you will see from earlier messages, the confused user is both quite real 
> and *is* on this list. Nor, mind you, are pedagogical concerns to be 
> trivialized; they are serious concerns for the design of the language. On 
> what grounds do you assert that something is "not confusing at all" when 
> there has been testimony saying "it was confusing to me"?
> 
> Some of us on this list interact regularly with novice coders. I draw upon 
> these experiences here. Do you have some special insight you'd like to share 
> in that regard?
> On Tue, Jun 14, 2016 at 20:57 Jon Akhtar  > wrote:
> How about the goal of it being a delightful language to program in. I think 
> that is getting lost in proposals like these. Optimizing for some mythical 
> new user, who really isn’t present on this list to give an opinion seems like 
> a false argument to make, and your technical sophistication makes you a less 
> qualified than most to say what is and what isn’t confusing to new users 
> because you haven’t been one in a long time.
> 
> -1 Leve it in. It is perfectly simple as is. Not confusing at all. There are 
> far more confusing aspects to the language than this.
> 
> Cheers

Yet another case from a few minutes ago:

rullie : hi, could someone walk me through this 
http://pastie.org/10887040 
[3:08pm] rullie : why is it that for loop through an lazy 
infinite sequence does not terminate even with the where clause invovled?
[
[3:08pm] mikeash : "where" means "skip iterations when this 
condition is not true"
[3:08pm] mikeash : it doesn't mean "halt the loop when this is 
not true"
[3:08pm] rullie : oh whoa.. ok
[3:09pm] mikeash : it can't know that you'll never see another 
value < 100, so  it keeps on going
[3:09pm] rullie : ok, i completely misunderstood the where 
clause then
[3:10pm] mikeash : I can see how it might look like it does that
[3:10pm] rullie : is there a syntax that achieves what i want to 
do without having to have a if-break in the loop?

-- E
p.s. Posted with permission from both participants

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

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

[Xiaodi Wu via swift-evolution]

On Wed, Jun 15, 2016 at 4:58 PM, Dany St-Amant via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Le 15 juin 2016 à 17:23, Jean-Daniel Dupas via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >
> >
> >> Le 13 juin 2016 à 17:26, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> a écrit :
> >>
> >>
> >>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I am 100% with Charlie on this. Expressiveness has to do with the
> *effectiveness* of conveying a thought or a feeling.
> >>>
> >>> Keep "where". It is expressive. It conveys a specific idea effectively
> and concisely.
> >>
> >> For those of you in favor of retaining `where`, how do you feel about
> adding `while`, `until`, `unless`, etc?
> >>
> >> — E
> >
> > What I like is the possibility to iterate over a filtered list using a
> ‘single’ statement, not the keyword itself. If you propose to replace where
> by something less confusing, or add other keywords, I’m all for it.
> >
>
> For the folks who like the 'where' and do not like the 'guard .. else
> continue', (also considering in the equation the suggestion of renaming
> 'where' by 'if'). One can get the 'where' syntax without the 'where'  at
> the cost of one indentation level and the set of curly braces.
>
> for element in dataArray {
>   if condition {
> doWork()
>   }
> }
>
> versus
>
> for element in dataArray where condition {
>   doWork()
> }
>

...and (not that I would advocate for this as the best style), you could
simulate the keyword with a slightly funny indentation:

```
for element in dataArray { if condition {
  doWork()
}}
```

(...and if we're counting letters typed as a metric for terseness, not that
I would advocate that metric, `where` and `if {}` are both exactly five...)


> Dany, slowly shifting into the "what's the point of keeping 'where'" camp
>

:)


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

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

[Dany St-Amant via swift-evolution]

> Le 15 juin 2016 à 17:23, Jean-Daniel Dupas via swift-evolution 
>  a écrit :
> 
> 
>> Le 13 juin 2016 à 17:26, Erica Sadun via swift-evolution 
>>  a écrit :
>> 
>> 
>>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution 
>>>  wrote:
>>> 
>>> I am 100% with Charlie on this. Expressiveness has to do with the 
>>> *effectiveness* of conveying a thought or a feeling.
>>> 
>>> Keep "where". It is expressive. It conveys a specific idea effectively and 
>>> concisely.
>> 
>> For those of you in favor of retaining `where`, how do you feel about adding 
>> `while`, `until`, `unless`, etc?
>> 
>> — E
> 
> What I like is the possibility to iterate over a filtered list using a 
> ‘single’ statement, not the keyword itself. If you propose to replace where 
> by something less confusing, or add other keywords, I’m all for it.
> 

For the folks who like the 'where' and do not like the 'guard .. else 
continue', (also considering in the equation the suggestion of renaming 'where' 
by 'if'). One can get the 'where' syntax without the 'where'  at the cost of 
one indentation level and the set of curly braces.

for element in dataArray {
  if condition {
doWork()
  }
}

versus

for element in dataArray where condition {
  doWork()
}

Dany, slowly shifting into the "what's the point of keeping 'where'" camp
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jean-Daniel Dupas via swift-evolution]

> Le 13 juin 2016 à 17:26, Erica Sadun via swift-evolution 
>  a écrit :
> 
> 
>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution 
>>  wrote:
>> 
>> I am 100% with Charlie on this. Expressiveness has to do with the 
>> *effectiveness* of conveying a thought or a feeling.
>> 
>> Keep "where". It is expressive. It conveys a specific idea effectively and 
>> concisely.
> 
> For those of you in favor of retaining `where`, how do you feel about adding 
> `while`, `until`, `unless`, etc?
> 
> — E

What I like is the possibility to iterate over a filtered list using a ‘single’ 
statement, not the keyword itself. If you propose to replace where by something 
less confusing, or add other keywords, I’m all for it.


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

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

[Haravikk via swift-evolution]

> On 15 Jun 2016, at 03:43, Jo Albright  wrote:
> 
> This is probably going to get lost in this massive chain. But I am going to 
> try to throw out a solution that I am not currently finding in this 
> conversation.
> 
> There is a huge battle between removing and keeping keywords based on 
> understanding. In my opinion keywords have a tendency to create more 
> confusion than any other part of the language. We have a great tool in place 
> to help teach developers what API methods and variables are and how they are 
> to be used. Using “Quick Help” you can easily learn more about that 
> declaration that didn’t make sense. 
> 
> Currently we have a lot of keywords that could do different things… for 
> example “in” is used in for loops to and also used in closure syntax. This 
> can create confusion easily and at some point start a proposal such as this 
> one. Instead of removing confusing pieces of a language, what about teaching 
> others what the keywords do and how they should be used. If Quick Help was 
> built to inform of what the keyword was doing in its current context, the 
> developer could easily make sense of what is going on and choose to correctly 
> use the syntax the way it is supposed to be used. You could even build in 
> suggestions for other keywords that may have relevance. 
> 
> Another example would be “return”. When teaching I noticed a lot of new 
> developers didn’t understand that no lines of code would run after it, but 
> then would get confused that you had to pass values on the same line to 
> return a value. Having Quick Help to not only explain how return works but 
> also tell you what Type it is expecting (including Void) would be very 
> helpful in learning.
> 
> Whether or not “where” gets removed from for loops. I would really love the 
> Apple team to think about extending Quick Help to work with other parts of 
> syntax like keywords.
> 
> Imagine a new user trying to figure out what “import”, “guard”, “defer”, 
> “lazy”, etc mean. They have to google or look through docs… Quick Help could 
> instantly give them more information without leaving their code.
> 
> Thanks,
> Jo

This is a really fantastic idea! Actually a big issue with many keywords is 
that they’re often such common words that they’re very hard to search for 
without being given more context (which is in itself a skill, I’m still caught 
out searching for things that others find with very similar yet subtly 
different search terms).

I wonder where the correct place to suggest this would be, as it will require 
some kind of documenting mechanism for keywords, as well as the means to expose 
it inside Xcode, so possibly an Xcode feature? Not sure, but I think it’s 
absolutely worth exploring! I doubt anyone will mind if it gets a thread here 
on swift-evolution in the mean, as like you say it runs the risk of being 
buried here in this thread.


On which note I really do think the discussion on actually removing where has 
run its course as it’s just going back and forth with little to no change in 
arguments. I think it’s premature to remove where from for loops until after 
the removal of where from conditionals has actually gone through and been in 
the wild some time, as it may well affect how confusing (or not) it is on for 
loops, plus it’d be nice to spend some time exploring other options like Jo’s, 
and Brent/Erica’s moving of the keyword, changes and/or additions to the 
keywords and so-on, which have been comparatively forgotten.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

> On Jun 15, 2016, at 3:57 AM, Jon Akhtar via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> How about the goal of it being a delightful language to program in.

Historyprooves that goals are rarely enterely wrong... It is how they are 
carried out that more often is questionable.


> I think that is getting lost in proposals like these. Optimizing for some 
> mythical new user, who really isn’t present on this list to give an opinion 
> seems like a false argument to make, and your technical sophistication makes 
> you a less qualified than most to say what is and what isn’t confusing to new 
> users because you haven’t been one in a long time.

Now the problem with that is : do you design for day 1 or do you design for 
day-n (where n > bigEnoughToDoLot). I hope NEITHER, which makes hte complete 
beginer equally disqualified as I am then. Swift is here to stay for next 20 
years at least... it can't just be designed for the extremes, and the role of 
chris and team is to see past the knee-jerk reactions of newcomers to see how 
they can put mechanisms in place that will secure the future. 

> -1 Leve it in. It is perfectly simple as is. Not confusing at all. There are 
> far more confusing aspects to the language than this.

But there are limited opportunity to hide great power behind simple looking 
constructs, and that is a fact, regardless of the number of users who can 
see/understand it. Objc thrived for 30 years because the apple world was very 
closed onto itself. Today arguably the most powerful language (richness of 
abstractions, universality) for writing appleOS apps is in the hands of 
microsoft. Maybe apple will settle for this situation, leaving people who feel 
limited by swift to switch to c#. But make no mistake, other languages will 
come (rust is already usable to make ios apps), and many of the people who are 
7 today and learning, will already feel limited 2 years from now if swift does 
not step up where it can.

> 
> Cheers
> 
> From: <swift-evolution-boun...@swift.org> on behalf of Xiaodi Wu via 
> swift-evolution <swift-evolution@swift.org>
> Reply-To: Xiaodi Wu <xiaodi...@gmail.com>
> Date: Tuesday, June 14, 2016 at 13:50
> To: "L. Mihalkovic" <laurent.mihalko...@gmail.com>, David Waite 
> <da...@alkaline-solutions.com>
> Cc: swift-evolution <swift-evolution@swift.org>
> Subject: Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops
> 
> Why are you unhappy about this design goal? Simple != simplistic, and 
> powerful != complicated. Approachability has to do with the slope of the 
> learning curve, not how high the curve goes.
> 
> 
>> On Tue, Jun 14, 2016 at 14:18 L. Mihalkovic <laurent.mihalko...@gmail.com> 
>> wrote:
>> 
>> 
>> Regards
>> (From mobile)
>> 
>> On Jun 14, 2016, at 7:16 PM, David Waite via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>> I’m a bit late to this conversation, and I don’t totally understand the 
>>> goal.
>>> 
>>> There are a *lot* of things you can do in for…in loop with pattern matching 
>>> that also would supposedly go against this interpretation of 
>>> approachability. Pattern matching in general might be considered to go 
>>> against this interpretation.
>>> 
>>> Is this pitch saying statements such as:
>>> 
>>> for i in 1..<100 where i%2 == 1 {…} 
>>> 
>>> should be disallowed, while statements like
>>> 
>>> for case let view? in views { … }
>>> 
>>> are still approachable enough to warrant being supported in the language?
>>> 
>>> FWIW, I wouldn’t support removing where based on current arguments without 
>>> either the keyword “where" being eliminated completely from the language, 
>>> and/or adding equivalent intuitive functionality to Sequence with 
>>> same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…). 
>>> 
>>> I’ve known about and used the feature since it was first added to Swift 
>>> (learned via the language book), and don’t fully understand the confusion 
>>> that some developers may have - especially since ‘while’ is already a 
>>> keyword and could have been used if that was the actual semantics.
>>> 
>>> -DW
>>> 
>>>> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> And from the WWDC Platforms SOTU: "Swift is super simple and 
>>>> approachable It's great as a first language. And in fact, we think 
>>>> this is so important that wh

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

[Brent Royal-Gordon via swift-evolution]

> What about just this?
> for i % 2 == 0 in sequence { ... }
> 
> The first new identifier gets to be the index variable and subsequent new 
> identifiers are errors.

If that weren't a syntax error, I would expect it to loop over `[true, false, 
true, false, …]`.

-- 
Brent Royal-Gordon
Architechies

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

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

[David Sweeris via swift-evolution]

> On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
>> 
>> On Jun 8, 2016, at 9:36 PM, Brent Royal-Gordon > > wrote:
>> 
>>> Upon accepting SE-0099, the core team is removing `where` clauses from 
>>> condition clauses, writing "the 'where' keyword can be retired from its 
>>> purpose as a boolean condition introducer." 
>>> 
>>> Inspiried by Xiaodi Wu, I now propose removing `where` clauses from `for 
>>> in` loops, where they are better expressed (and read) as guard conditions. 
>> 
>> Do you propose to remove `for case` as well? That can equally be handled by 
>> a `guard case` in the loop body.
>> 
>> Alternate proposal: Move `where` clauses to be adjacent to the 
>> pattern—rather than the sequence expression—in a `for` loop, just as they 
>> are in these other syntaxes.
>> 
>>  for n where n.isOdd in 1...1_000 { … }
>> 
>> This makes them more consistent with the syntax in `switch` cases and 
>> `catch` statements, while also IMHO clarifying the role of the `where` 
>> clause as a filter on the elements seen by the loop.
> 
> 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
> }

What about just this?
for i % 2 == 0 in sequence { ... }

The first new identifier gets to be the index variable and subsequent new 
identifiers are errors.

- Dave Sweeris

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

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

[Xiaodi Wu via swift-evolution]

Why are you unhappy about this design goal? Simple != simplistic, and
powerful != complicated. Approachability has to do with the slope of the
learning curve, not how high the curve goes.


On Tue, Jun 14, 2016 at 14:18 L. Mihalkovic 
wrote:

>
>
> Regards
> (From mobile)
>
> On Jun 14, 2016, at 7:16 PM, David Waite via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I’m a bit late to this conversation, and I don’t totally understand the
> goal.
>
> There are a *lot* of things you can do in for…in loop with pattern
> matching that also would supposedly go against this interpretation of
> approachability. Pattern matching in general might be considered to go
> against this interpretation.
>
> Is this pitch saying statements such as:
>
> for i in 1..<100 where i%2 == 1 {…}
>
> should be disallowed, while statements like
>
> for case let view? in views { … }
>
> are still approachable enough to warrant being supported in the language?
>
> FWIW, I wouldn’t support removing where based on current arguments without
> either the keyword “where" being eliminated completely from the language,
> and/or adding equivalent intuitive functionality to Sequence with
> same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…).
>
> I’ve known about and used the feature since it was first added to Swift
> (learned via the language book), and don’t fully understand the confusion
> that some developers may have - especially since ‘while’ is already a
> keyword and could have been used if that was the actual semantics.
>
> -DW
>
> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> And from the WWDC Platforms SOTU: "Swift is super simple and
> approachable It's great as a first language. And in fact, we think this
> is so important that when we designed Swift this was an explicit design
> goal."
>
>
> Yup... Doesn't bode well for power users... "Swift.. Address your needs
> from 7 till 77... unifies the entire family"
>
> I would be absolutely against adding any more sugar to the for loop. In
> that sense, `where` sets a terrible example that certain features of
> sequences deserve contextual sugar. (And before someone points it out
> again, I've already argued why `for...in` holds its own weight, namely
> difficulty of writing a correct `while` replacement and progressive
> disclosure to the learner so that the concept of iterators can be learned
> afterwards.)
>
> In short, I would very much be opposed to adding keywords "for fun."
>
>
> ___
> 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

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 14, 2016, at 7:16 PM, David Waite via swift-evolution 
>  wrote:
> 
> I’m a bit late to this conversation, and I don’t totally understand the goal.
> 
> There are a *lot* of things you can do in for…in loop with pattern matching 
> that also would supposedly go against this interpretation of approachability. 
> Pattern matching in general might be considered to go against this 
> interpretation.
> 
> Is this pitch saying statements such as:
> 
>   for i in 1..<100 where i%2 == 1 {…} 
> 
> should be disallowed, while statements like
> 
>   for case let view? in views { … }
> 
> are still approachable enough to warrant being supported in the language?
> 
> FWIW, I wouldn’t support removing where based on current arguments without 
> either the keyword “where" being eliminated completely from the language, 
> and/or adding equivalent intuitive functionality to Sequence with same-class 
> performance, e.g. a .where(...) equivalent to .lazy.filter(…). 
> 
> I’ve known about and used the feature since it was first added to Swift 
> (learned via the language book), and don’t fully understand the confusion 
> that some developers may have - especially since ‘while’ is already a keyword 
> and could have been used if that was the actual semantics.
> 
> -DW
> 
>> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> And from the WWDC Platforms SOTU: "Swift is super simple and 
>> approachable It's great as a first language. And in fact, we think this 
>> is so important that when we designed Swift this was an explicit design 
>> goal."

Yup... Doesn't bode well for power users... "Swift.. Address your needs from 7 
till 77... unifies the entire family"

>> I would be absolutely against adding any more sugar to the for loop. In that 
>> sense, `where` sets a terrible example that certain features of sequences 
>> deserve contextual sugar. (And before someone points it out again, I've 
>> already argued why `for...in` holds its own weight, namely difficulty of 
>> writing a correct `while` replacement and progressive disclosure to the 
>> learner so that the concept of iterators can be learned afterwards.)
>> 
>> In short, I would very much be opposed to adding keywords "for fun."
> 
> ___
> 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

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

[Xiaodi Wu via swift-evolution]

We're going in circles again. I addressed this with relation to `guard`,
and I would reply in the same way about `for case`:

The fact is that there are even experienced users of Swift who see `where`
and affirmatively believe it does what it does not do. The same cannot be
said for `for case`. That is, a user might say, 'What in the world does for
case mean?', but even a totally new user is unlikely to say, 'I can guess
what for case means, and it means [something that for case does not in fact
mean].'

On Tue, Jun 14, 2016 at 12:55 Ryan Lovelett via swift-evolution <
swift-evolution@swift.org> wrote:

> On Tue, Jun 14, 2016, at 01:37 PM, Xiaodi Wu via swift-evolution wrote:
>
> On Tue, Jun 14, 2016 at 12:16 PM, David Waite <
> da...@alkaline-solutions.com> wrote:
>
> I’m a bit late to this conversation, and I don’t totally understand the
> goal.
>
> There are a *lot* of things you can do in for…in loop with pattern
> matching that also would supposedly go against this interpretation of
> approachability. Pattern matching in general might be considered to go
> against this interpretation.
>
> Is this pitch saying statements such as:
>
> for i in 1..<100 where i%2 == 1 {…}
>
> should be disallowed, while statements like
>
> for case let view? in views { … }
>
> are still approachable enough to warrant being supported in the language?
>
>
> Language design has to weigh many factors simultaneously, I think you'd
> agree. The argument, essentially, is that `where` is not approachable *for
> the functionality that it provides* (namely, as an alternative for a
> trivial `guard...continue` statement). Pattern matching is daunting no
> doubt, but it offers functionality not conducive to much simpler syntax.
> (Or could it be much simpler? If so, then I would support a proposal to
> that effect.)
>
> Put simply, `where` is a less-than-straightforward expression of a very
> straightforward concept (filtering an array), whereas pattern matching is
> an advanced concept with a commensurately difficult syntax. Others have
> brought up generics, for example, but again that's an advanced *concept*;
> filtering an array is not.
>
>
> So you do not see that for case syntax as "a less-than-straightforward
> expression of a very straightforward concept (filtering an array)"?
>
> That's strange to me. Seems like that would be the _poster_ child for such
> a syntax.
>
> enum Things {
>   case One
>   case Two
>   case Three
>   case Four
> }
>
> let things: [Things] = [.One, .Two, .One, .Three, .Four, .One]
> for case .One in things {
>   print("Found a .One")
> }
>
> That code prints "Found a .One" three times. If the `where` syntax is
> non-obvious with regard to `continue` or `break` then surely _that_ code is
> down right opaque!
>
>
>
>
>
> FWIW, I wouldn’t support removing where based on current arguments without
> either the keyword “where" being eliminated completely from the language,
> and/or adding equivalent intuitive functionality to Sequence with
> same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…).
>
>
>
>
> I feel bad sending clearly passionate people over to crush another
> conversation, but I think you'll find in the Swift repository the
> beginnings of some explorations by a certain member of the core team to
> rename `.filter()` to `.where()` :D
>
> As to whether certain methods should be lazy or eager by default, that's a
> discussion certainly appropriate for this list.
>
>
> I’ve known about and used the feature since it was first added to Swift
> (learned via the language book), and don’t fully understand the confusion
> that some developers may have - especially since ‘while’ is already a
> keyword and could have been used if that was the actual semantics.
>
>
> One source of confusion was that `while...where` was supported and had
> breaking semantics. Now that's gone with SE-0099. Still, the point is that
> `where` is favored by some *because* you don't have to write explicitly
> what happens when something doesn't pass the filter, whereas the
> counterpoint argument is that not writing explicitly what happens when a
> rejected element is encountered *is* the very source of confusion.
>
>
>
>
> -DW
>
>
>
> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> And from the WWDC Platforms SOTU: "Swift is super simple and
> approachable It's great as a first language. And in fact, we think this
> is so important that when we designed Swift this was an explicit design
> goal."
>
> I would be absolutely against adding any more sugar to the for loop. In
> that sense, `where` sets a terrible example that certain features of
> sequences deserve contextual sugar. (And before someone points it out
> again, I've already argued why `for...in` holds its own weight, namely
> difficulty of writing a correct `while` replacement and progressive
> disclosure to the learner so that the concept of iterators can be learned
> afterwards.)
>
> In 

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

[Ryan Lovelett via swift-evolution]

On Tue, Jun 14, 2016, at 01:37 PM, Xiaodi Wu via swift-evolution wrote:
> On Tue, Jun 14, 2016 at 12:16 PM, David Waite  solutions.com> wrote:
>> I’m a bit late to this conversation, and I don’t totally understand
>> the goal.
>>
>> There are a *lot* of things you can do in for…in loop with pattern
>> matching that also would supposedly go against this interpretation of
>> approachability. Pattern matching in general might be considered to
>> go against this interpretation.
>>
>> Is this pitch saying statements such as:
>>
>> for i in 1..<100 where i%2 == 1 {…}
>>
>> should be disallowed, while statements like
>>
>> for case let view? in views { … }
>>
>> are still approachable enough to warrant being supported in the
>> language?
>
> Language design has to weigh many factors simultaneously, I think
> you'd agree. The argument, essentially, is that `where` is not
> approachable *for the functionality that it provides* (namely, as an
> alternative for a trivial `guard...continue` statement). Pattern
> matching is daunting no doubt, but it offers functionality not
> conducive to much simpler syntax. (Or could it be much simpler? If so,
> then I would support a proposal to that effect.)
>
> Put simply, `where` is a less-than-straightforward expression of a
> very straightforward concept (filtering an array), whereas pattern
> matching is an advanced concept with a commensurately difficult
> syntax. Others have brought up generics, for example, but again that's
> an advanced *concept*; filtering an array is not.
 
So you do not see that for case syntax as "a less-than-straightforward
expression of a very straightforward concept (filtering an array)"?
 
That's strange to me. Seems like that would be the _poster_ child for
such a syntax.
 
enum Things {
case One
case Two
case Three
case Four
}
 
let things: [Things] = [.One, .Two, .One, .Three, .Four, .One]
for case .One in things {
print("Found a .One")
}
 
That code prints "Found a .One" three times. If the `where` syntax is
non-obvious with regard to `continue` or `break` then surely _that_ code
is down right opaque!
 
>
>>
>> FWIW, I wouldn’t support removing where based on current arguments
>> without either the keyword “where" being eliminated completely from
>> the language, and/or adding equivalent intuitive functionality to
>> Sequence with same-class performance, e.g. a .where(...) equivalent
>> to .lazy.filter(…).
>>
>>
>
> I feel bad sending clearly passionate people over to crush another
> conversation, but I think you'll find in the Swift repository the
> beginnings of some explorations by a certain member of the core team
> to rename `.filter()` to `.where()` :D
>
> As to whether certain methods should be lazy or eager by default,
> that's a discussion certainly appropriate for this list.
>
>> I’ve known about and used the feature since it was first added to
>> Swift (learned via the language book), and don’t fully understand the
>> confusion that some developers may have - especially since ‘while’ is
>> already a keyword and could have been used if that was the actual
>> semantics.
>
> One source of confusion was that `while...where` was supported and had
> breaking semantics. Now that's gone with SE-0099. Still, the point is
> that `where` is favored by some *because* you don't have to write
> explicitly what happens when something doesn't pass the filter,
> whereas the counterpoint argument is that not writing explicitly what
> happens when a rejected element is encountered *is* the very source of
> confusion.
>
>>
>>
>> -DW
>>
>>
>>> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>> And from the WWDC Platforms SOTU: "Swift is super simple and
>>> approachable It's great as a first language. And in fact, we
>>> think this is so important that when we designed Swift this was an
>>> explicit design goal."
>>>
>>> I would be absolutely against adding any more sugar to the for loop.
>>> In that sense, `where` sets a terrible example that certain features
>>> of sequences deserve contextual sugar. (And before someone points it
>>> out again, I've already argued why `for...in` holds its own weight,
>>> namely difficulty of writing a correct `while` replacement and
>>> progressive disclosure to the learner so that the concept of
>>> iterators can be learned afterwards.)
>>>
>>> In short, I would very much be opposed to adding keywords "for fun."
>>
>>
> _
> 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

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

[Xiaodi Wu via swift-evolution]

On Tue, Jun 14, 2016 at 12:37 PM, Xiaodi Wu  wrote:

> On Tue, Jun 14, 2016 at 12:16 PM, David Waite <
> da...@alkaline-solutions.com> wrote:
>
>> I’m a bit late to this conversation, and I don’t totally understand the
>> goal.
>>
>> There are a *lot* of things you can do in for…in loop with pattern
>> matching that also would supposedly go against this interpretation of
>> approachability. Pattern matching in general might be considered to go
>> against this interpretation.
>>
>> Is this pitch saying statements such as:
>>
>> for i in 1..<100 where i%2 == 1 {…}
>>
>> should be disallowed, while statements like
>>
>> for case let view? in views { … }
>>
>> are still approachable enough to warrant being supported in the language?
>>
>
> Language design has to weigh many factors simultaneously, I think you'd
> agree. The argument, essentially, is that `where` is not approachable *for
> the functionality that it provides* (namely, as an alternative for a
> trivial `guard...continue` statement). Pattern matching is daunting no
> doubt, but it offers functionality not conducive to much simpler syntax.
> (Or could it be much simpler? If so, then I would support a proposal to
> that effect.)
>
> Put simply, `where` is a less-than-straightforward expression of a very
> straightforward concept (filtering an array), whereas pattern matching is
> an advanced concept with a commensurately difficult syntax. Others have
> brought up generics, for example, but again that's an advanced *concept*;
> filtering an array is not.
>
>
>>
>> FWIW, I wouldn’t support removing where based on current arguments
>> without either the keyword “where" being eliminated completely from the
>> language
>>
>
I should add, if this proposal is adopted along with the enclosed
suggestion to replace `where` with `if` in `case` and `catch`, the `where`
keyword would be completely eliminated except in the context of generics.
If the enclosed suggestion is not adopted here, alternatives will follow on
shortly.


> and/or adding equivalent intuitive functionality to Sequence with
>> same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…).
>>
>>
> I feel bad sending clearly passionate people over to crush another
> conversation, but I think you'll find in the Swift repository the
> beginnings of some explorations by a certain member of the core team to
> rename `.filter()` to `.where()` :D
>
> As to whether certain methods should be lazy or eager by default, that's a
> discussion certainly appropriate for this list.
>
>
>> I’ve known about and used the feature since it was first added to Swift
>> (learned via the language book), and don’t fully understand the confusion
>> that some developers may have - especially since ‘while’ is already a
>> keyword and could have been used if that was the actual semantics.
>>
>
> One source of confusion was that `while...where` was supported and had
> breaking semantics. Now that's gone with SE-0099. Still, the point is that
> `where` is favored by some *because* you don't have to write explicitly
> what happens when something doesn't pass the filter, whereas the
> counterpoint argument is that not writing explicitly what happens when a
> rejected element is encountered *is* the very source of confusion.
>
>
>>
>> -DW
>>
>> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> And from the WWDC Platforms SOTU: "Swift is super simple and
>> approachable It's great as a first language. And in fact, we think this
>> is so important that when we designed Swift this was an explicit design
>> goal."
>>
>> I would be absolutely against adding any more sugar to the for loop. In
>> that sense, `where` sets a terrible example that certain features of
>> sequences deserve contextual sugar. (And before someone points it out
>> again, I've already argued why `for...in` holds its own weight, namely
>> difficulty of writing a correct `while` replacement and progressive
>> disclosure to the learner so that the concept of iterators can be learned
>> afterwards.)
>>
>> In short, I would very much be opposed to adding keywords "for fun."
>>
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Tue, Jun 14, 2016 at 12:16 PM, David Waite 
wrote:

> I’m a bit late to this conversation, and I don’t totally understand the
> goal.
>
> There are a *lot* of things you can do in for…in loop with pattern
> matching that also would supposedly go against this interpretation of
> approachability. Pattern matching in general might be considered to go
> against this interpretation.
>
> Is this pitch saying statements such as:
>
> for i in 1..<100 where i%2 == 1 {…}
>
> should be disallowed, while statements like
>
> for case let view? in views { … }
>
> are still approachable enough to warrant being supported in the language?
>

Language design has to weigh many factors simultaneously, I think you'd
agree. The argument, essentially, is that `where` is not approachable *for
the functionality that it provides* (namely, as an alternative for a
trivial `guard...continue` statement). Pattern matching is daunting no
doubt, but it offers functionality not conducive to much simpler syntax.
(Or could it be much simpler? If so, then I would support a proposal to
that effect.)

Put simply, `where` is a less-than-straightforward expression of a very
straightforward concept (filtering an array), whereas pattern matching is
an advanced concept with a commensurately difficult syntax. Others have
brought up generics, for example, but again that's an advanced *concept*;
filtering an array is not.


>
> FWIW, I wouldn’t support removing where based on current arguments without
> either the keyword “where" being eliminated completely from the language,
> and/or adding equivalent intuitive functionality to Sequence with
> same-class performance, e.g. a .where(...) equivalent to .lazy.filter(…).
>
>
I feel bad sending clearly passionate people over to crush another
conversation, but I think you'll find in the Swift repository the
beginnings of some explorations by a certain member of the core team to
rename `.filter()` to `.where()` :D

As to whether certain methods should be lazy or eager by default, that's a
discussion certainly appropriate for this list.


> I’ve known about and used the feature since it was first added to Swift
> (learned via the language book), and don’t fully understand the confusion
> that some developers may have - especially since ‘while’ is already a
> keyword and could have been used if that was the actual semantics.
>

One source of confusion was that `while...where` was supported and had
breaking semantics. Now that's gone with SE-0099. Still, the point is that
`where` is favored by some *because* you don't have to write explicitly
what happens when something doesn't pass the filter, whereas the
counterpoint argument is that not writing explicitly what happens when a
rejected element is encountered *is* the very source of confusion.


>
> -DW
>
> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> And from the WWDC Platforms SOTU: "Swift is super simple and
> approachable It's great as a first language. And in fact, we think this
> is so important that when we designed Swift this was an explicit design
> goal."
>
> I would be absolutely against adding any more sugar to the for loop. In
> that sense, `where` sets a terrible example that certain features of
> sequences deserve contextual sugar. (And before someone points it out
> again, I've already argued why `for...in` holds its own weight, namely
> difficulty of writing a correct `while` replacement and progressive
> disclosure to the learner so that the concept of iterators can be learned
> afterwards.)
>
> In short, I would very much be opposed to adding keywords "for fun."
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

I’m a bit late to this conversation, and I don’t totally understand the goal.

There are a *lot* of things you can do in for…in loop with pattern matching 
that also would supposedly go against this interpretation of approachability. 
Pattern matching in general might be considered to go against this 
interpretation.

Is this pitch saying statements such as:

for i in 1..<100 where i%2 == 1 {…} 

should be disallowed, while statements like

for case let view? in views { … }

are still approachable enough to warrant being supported in the language?

FWIW, I wouldn’t support removing where based on current arguments without 
either the keyword “where" being eliminated completely from the language, 
and/or adding equivalent intuitive functionality to Sequence with same-class 
performance, e.g. a .where(...) equivalent to .lazy.filter(…). 

I’ve known about and used the feature since it was first added to Swift 
(learned via the language book), and don’t fully understand the confusion that 
some developers may have - especially since ‘while’ is already a keyword and 
could have been used if that was the actual semantics.

-DW

> On Jun 14, 2016, at 10:32 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> And from the WWDC Platforms SOTU: "Swift is super simple and approachable 
> It's great as a first language. And in fact, we think this is so important 
> that when we designed Swift this was an explicit design goal."
> 
> I would be absolutely against adding any more sugar to the for loop. In that 
> sense, `where` sets a terrible example that certain features of sequences 
> deserve contextual sugar. (And before someone points it out again, I've 
> already argued why `for...in` holds its own weight, namely difficulty of 
> writing a correct `while` replacement and progressive disclosure to the 
> learner so that the concept of iterators can be learned afterwards.)
> 
> In short, I would very much be opposed to adding keywords "for fun."

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

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

[Xiaodi Wu via swift-evolution]

And from the WWDC Platforms SOTU: "Swift is super simple and
approachable It's great as a first language. And in fact, we think this
is so important that when we designed Swift this was an explicit design
goal."

I would be absolutely against adding any more sugar to the for loop. In
that sense, `where` sets a terrible example that certain features of
sequences deserve contextual sugar. (And before someone points it out
again, I've already argued why `for...in` holds its own weight, namely
difficulty of writing a correct `while` replacement and progressive
disclosure to the learner so that the concept of iterators can be learned
afterwards.)

In short, I would very much be opposed to adding keywords "for fun."

On Tue, Jun 14, 2016 at 11:18 AM Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> FWIW I don't think we need all "4", just like we don't need `unless` as a
> pair to current `if` or `until` as a pair for current `while` loop.
>
> I.e. we have "continue" with current `where`, and you can use boolean
> inversion `!`. As for "break"(while) - my opinion the for-in loop will be
> more powerful and adds fun for coding (from wwdc keynote - "Swift is a
> powerful language.. writing Swift code is *fun*..." my opinion: using
> guard-continue or guard-break is *not* fun ).
>
> So in your words, it is better add *one* then remove *one*.
>
> The only question I'm not sure about if we should keep 'where' and 'while'
> keywords for these features, or rename them. For me it's OK to have 'where'
> and 'while' but probably I'll support another more clear keywords.
>
> On 14.06.2016 18:01, Erica Sadun via swift-evolution wrote:
> >
> >> On Jun 14, 2016, at 7:50 AM, plx via swift-evolution <
> swift-evolution@swift.org> wrote:
> >> For those particular keywords, I’d prefer having them (or equivalents).
> I’m not sure if I’d prefer having *all* of them—`where/unless` and
> `while/until`—or just one from each “pair”…I could go either way.
> >
> > In the proposal, my recommendations for including all 4 are:
> >
> > break: while / until
> > continue: if (formerly `where`) / unless
> >
> > As the thread has had sufficient redundancy, I'll refrain from making my
> case again for why I think it's better to remove the one than add the three.
> >
> > -- 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

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

[Vladimir.S via swift-evolution]

FWIW I don't think we need all "4", just like we don't need `unless` as a 
pair to current `if` or `until` as a pair for current `while` loop.


I.e. we have "continue" with current `where`, and you can use boolean 
inversion `!`. As for "break"(while) - my opinion the for-in loop will be 
more powerful and adds fun for coding (from wwdc keynote - "Swift is a 
powerful language.. writing Swift code is *fun*..." my opinion: using 
guard-continue or guard-break is *not* fun ).


So in your words, it is better add *one* then remove *one*.

The only question I'm not sure about if we should keep 'where' and 'while' 
keywords for these features, or rename them. For me it's OK to have 'where' 
and 'while' but probably I'll support another more clear keywords.


On 14.06.2016 18:01, Erica Sadun via swift-evolution wrote:



On Jun 14, 2016, at 7:50 AM, plx via swift-evolution 
 wrote:
For those particular keywords, I’d prefer having them (or equivalents). I’m not 
sure if I’d prefer having *all* of them—`where/unless` and `while/until`—or 
just one from each “pair”…I could go either way.


In the proposal, my recommendations for including all 4 are:

break: while / until
continue: if (formerly `where`) / unless

As the thread has had sufficient redundancy, I'll refrain from making my case 
again for why I think it's better to remove the one than add the three.

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

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

[Xiaodi Wu via swift-evolution]

The equivalent in Swift would be .filter(), and you're free to use it if
you prefer to express yourself that way.

Notice how these are almost never paired with loops. It's like mixing
chocolate and steak.

On Tue, Jun 14, 2016 at 8:50 AM plx via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Jun 13, 2016, at 10:26 AM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> I am 100% with Charlie on this. Expressiveness has to do with the
> *effectiveness* of conveying a thought or a feeling.
> >>
> >> Keep "where". It is expressive. It conveys a specific idea effectively
> and concisely.
> >
> > For those of you in favor of retaining `where`, how do you feel about
> adding `while`, `until`, `unless`, etc?
>
> In the interest of advancing the “what kind of language would I prefer
> swift become?”, here are my final thoughts on this topic:
>
> For those particular keywords, I’d prefer having them (or equivalents).
> I’m not sure if I’d prefer having *all* of them—`where/unless` and
> `while/until`—or just one from each “pair”…I could go either way.
>
> As a general consideration, I’d be in favor of having them b/c I’d really
> like Swift to have a comprehension-style construct (and associated syntax
> etc.).
>
> Comprehension syntax is IMHO pretty common outside the C family—within the
> C family really only C# has something like it—and in general comprehension
> syntax has pretty similar structure from language to language. This link
> illustrates the syntax for 28 languages’  comprehension constructs, so it
> isn’t a bad overview:
>
>
> https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(list_comprehension)
>
> …(note that “comprehension syntax” isn’t quite the same thing as “list
> comprehensions”, but for “comparative syntax” purposes that link should be
> sufficient).
>
> For me the appeal of “comprehension syntax” is that it allows writing code
> that feels more “semantic” than “mechanical”, and that paraphrases much
> closer to the intended meaning.
>
> Here’s a toy example:
>
>   // with a comprehension-like syntax
>   // outside loop: “what items do we care about?"
>   for visitor in queue where visitor.hasTicket until venue.isFull {
> // inside loop: “…and what do we do with them?"
> venue.admit(visitor)
>   }
>
> …which to my eyes paraphrases more-or-less how I’d describe what we’re
> doing:
>
> - “keep admitting visitors with tickets until the venue is full”
>
> …whereas without it, you get something like this:
>
>   // without comprehension-style syntax
>   // outside loop: where, mechanically, are we sourcing items from
>   for visitor in queue {
> // inside loop: muddled mix of filtering, app logic, and flow-control
> // filtering:
> guard visitor.hasTicket else { continue }
> // app logic:
> venue.admit(visitor)
> // flow-control:
> if venue.isFull { break }
>   }
>
> …which *is* closer to the underlying mechanics, but paraphrases more like
> something you'd see in a badly-translated 80s VCR programing manual:
>
> - “Start considering visitors. If the visitor doesn't have a ticket, move
> on to the next visitor. Otherwise, admit the visitor. If the venue is full,
> stop considering visitors.”
>
> Sure, they’re both equivalent—and even in the 80s, some people managed to
> program their VCRs!—but given the option I’d strongly prefer to write in
> the first style; I like having a clean segregation between “what items are
> of interest?” and “what do we do with them?”
>
> So that’s what I like about comprehension-like constructs.
>
> The current `for-in-where` is a bit of an anomaly; it could be grown into
> something a little richer—`for _ in _ where _ while _`  and/or `for _ in _
> where _ until _` (etc.).—or it could be dropped and some better construct
> proposed.
>
> But, my personal preference would be to keep it around until either the
> richer construct is available or definitively declared as “not swift-y, not
> happening”:
>
> - if a “comprehension” construct is approved, an automatic migrator would
> likely do a *much* better job translating those `for _ in _ where` loops
> than it’d do with their more-imperative equivalents
> - if a “comprehension” construct is definitively-rejected, at least I can
> keep using something I like until the hammer drops
>
> >
> > -- 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

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

[Erica Sadun via swift-evolution]

> On Jun 14, 2016, at 7:50 AM, plx via swift-evolution 
>  wrote:
> For those particular keywords, I’d prefer having them (or equivalents). I’m 
> not sure if I’d prefer having *all* of them—`where/unless` and 
> `while/until`—or just one from each “pair”…I could go either way.

In the proposal, my recommendations for including all 4 are:

break: while / until
continue: if (formerly `where`) / unless

As the thread has had sufficient redundancy, I'll refrain from making my case 
again for why I think it's better to remove the one than add the three.

-- E


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

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

[plx via swift-evolution]

> On Jun 13, 2016, at 10:26 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution 
>>  wrote:
>> 
>> I am 100% with Charlie on this. Expressiveness has to do with the 
>> *effectiveness* of conveying a thought or a feeling.
>> 
>> Keep "where". It is expressive. It conveys a specific idea effectively and 
>> concisely.
> 
> For those of you in favor of retaining `where`, how do you feel about adding 
> `while`, `until`, `unless`, etc?

In the interest of advancing the “what kind of language would I prefer swift 
become?”, here are my final thoughts on this topic:

For those particular keywords, I’d prefer having them (or equivalents). I’m not 
sure if I’d prefer having *all* of them—`where/unless` and `while/until`—or 
just one from each “pair”…I could go either way.

As a general consideration, I’d be in favor of having them b/c I’d really like 
Swift to have a comprehension-style construct (and associated syntax etc.).

Comprehension syntax is IMHO pretty common outside the C family—within the C 
family really only C# has something like it—and in general comprehension syntax 
has pretty similar structure from language to language. This link illustrates 
the syntax for 28 languages’  comprehension constructs, so it isn’t a bad 
overview:

https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(list_comprehension)

…(note that “comprehension syntax” isn’t quite the same thing as “list 
comprehensions”, but for “comparative syntax” purposes that link should be 
sufficient).

For me the appeal of “comprehension syntax” is that it allows writing code that 
feels more “semantic” than “mechanical”, and that paraphrases much closer to 
the intended meaning.

Here’s a toy example:

  // with a comprehension-like syntax
  // outside loop: “what items do we care about?"
  for visitor in queue where visitor.hasTicket until venue.isFull {
// inside loop: “…and what do we do with them?"
venue.admit(visitor)
  }

…which to my eyes paraphrases more-or-less how I’d describe what we’re doing:

- “keep admitting visitors with tickets until the venue is full”

…whereas without it, you get something like this:

  // without comprehension-style syntax
  // outside loop: where, mechanically, are we sourcing items from
  for visitor in queue {
// inside loop: muddled mix of filtering, app logic, and flow-control
// filtering:
guard visitor.hasTicket else { continue }
// app logic:
venue.admit(visitor)
// flow-control:
if venue.isFull { break }
  }

…which *is* closer to the underlying mechanics, but paraphrases more like 
something you'd see in a badly-translated 80s VCR programing manual:

- “Start considering visitors. If the visitor doesn't have a ticket, move on to 
the next visitor. Otherwise, admit the visitor. If the venue is full, stop 
considering visitors.”

Sure, they’re both equivalent—and even in the 80s, some people managed to 
program their VCRs!—but given the option I’d strongly prefer to write in the 
first style; I like having a clean segregation between “what items are of 
interest?” and “what do we do with them?”

So that’s what I like about comprehension-like constructs.

The current `for-in-where` is a bit of an anomaly; it could be grown into 
something a little richer—`for _ in _ where _ while _`  and/or `for _ in _ 
where _ until _` (etc.).—or it could be dropped and some better construct 
proposed.

But, my personal preference would be to keep it around until either the richer 
construct is available or definitively declared as “not swift-y, not 
happening”: 

- if a “comprehension” construct is approved, an automatic migrator would 
likely do a *much* better job translating those `for _ in _ where` loops than 
it’d do with their more-imperative equivalents
- if a “comprehension” construct is definitively-rejected, at least I can keep 
using something I like until the hammer drops

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

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

[Vladimir.S via swift-evolution]

On 13.06.2016 18:59, L. Mihalkovic via swift-evolution wrote:

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

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



Yes, if you know *for sure* it it will be "better outcome" tomorrow. I.e. 
we even don't have any thoughts about what LINQ for Swift can look like, 
and when we'll only start to discuss this(4.x? 5.x? 6.x?), but we 
definitely needs to remove handful feature now and then keep the hope it 
will return in more powerful way. Probably we need to be very close to 
situation when 'where' in 'for-in' loop prevents introduction of LINQ-like 
feature to remote this 'where'? (probably with for-in loop together).


Again, we have sugar of `for-in` to be able to iterate 
sequences in handy way, we need it only for this purpose. We 
have 'where' feature in 'for-in' to be able to filter the iterating 
sequence. Filtering is essential operation for sequences/collections 
(.filter is one of main 3 operations : filter/map/reduce). As we have a 
special sugar to iterate sequences I find it very logical to have in it a 
sugar to filter iterated sequences. Force people to use guard-continue 
instead of 'where' for me is equal to force to use 'while' loop to iterate 
sequences instead of `for-in` loop.


Also, as was mentioned, in some situations you want to apply logically 
'main' filter in 'where' clause and then use guard-continue for additional 
filters/checks in body.


And 'where' in for-in loops does exist now in Swift. IMO you need really 
strong arguments to remove it. I've read all the messages of Xiaodi and 
Erica(and others), and I didn't find any argument that clearly shows that 
'where' is a bad thing and must be removed, I saw your opinions or your 
view of Swift future or your understanding of Swift goals or your 
understanding of core-team thoughts or your preferable style for coding etc.


If it is not clear if 'where' has 'continue if fails' behavior - IMO we 
need to *rename* it. It is just not logically to remove the feature if 
keyword is not clear enough(*for some beginners who see it the first time) 
- make the keyword clear, then you have no main argument to remove the 
_feature_.

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

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

[Austin Zheng via swift-evolution]

> On Jun 14, 2016, at 1:22 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 14 Jun 2016, at 07:54, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> And a language feature being undocumented wouldn't explain why the entire 
>> stdlib uses it only three times :)
> 
> I sometimes wonder whether the stdlib is always the best example of pure 
> Swift coding practices, it has after all been developed while the language 
> itself is in flux so chunks of it were being written while language features 
> were actively changing, and it has a lot of patterns in it that I just don’t 
> use in Swift. For example, I still haven’t figured out why the Indexable 
> protocol has an IndexableBase parent (other than to make figuring out why my 
> types don’t conform a lot harder),

AFAIK this is because associated types currently can't define a recursive 
protocol conformance constraint. For example, `SignedIntegerType` has a 
`Distance` associated type which should also be a `SignedIntegerType`, but has 
to be implemented using a shadow protocol (`_SignedIntegerType`) instead.

> and there’s stuff going on in .gyb files that remains a mystery to me. 
> There’s also a lot of little hidden features that we don’t have access to in 
> our own code (I can't find a method that retrieves object identifiers, for 
> comparing two types without knowing what they are, outside of the stdlib for 
> example, yet you’ll find them used inside AnyIndex and similar types).

Is the publicly exposed `ObjectIdentifier` type what you're looking for?

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

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

[Haravikk via swift-evolution]

> On 14 Jun 2016, at 07:54, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> And a language feature being undocumented wouldn't explain why the entire 
> stdlib uses it only three times :)

I sometimes wonder whether the stdlib is always the best example of pure Swift 
coding practices, it has after all been developed while the language itself is 
in flux so chunks of it were being written while language features were 
actively changing, and it has a lot of patterns in it that I just don’t use in 
Swift. For example, I still haven’t figured out why the Indexable protocol has 
an IndexableBase parent (other than to make figuring out why my types don’t 
conform a lot harder), and there’s stuff going on in .gyb files that remains a 
mystery to me. There’s also a lot of little hidden features that we don’t have 
access to in our own code (I can't find a method that retrieves object 
identifiers, for comparing two types without knowing what they are, outside of 
the stdlib for example, yet you’ll find them used inside AnyIndex and similar 
types).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 14, 2016, at 8:41 AM, Charlie Monroe  wrote:
> 
>> I used to do low latency java for trading systems... the kind of coding 
>> where we would go out of our way to avoid ANY intraday gc activity (yes it 
>> can be done, even for parsing xml files). So we cared about a lot of 
>> things... But when you look at the numbers above on a 4_000_000 iterations 
>> loop and say the differential matters? I say you are probably using the 
>> wrong tools to write your code in the first place, and you should be using 
>> accelerate.
> 
> Yes, I say it does matter. Of course, 4 million iterations is a fictional 
> example that rarely occurrs on its own, but gives you an idea that there's 
> more going on behind the scenes other than pure iteration.
> 
> You're looking at it from a point where one app does one thing and the loop 
> will have just a few iterations. Try to look at it from a point where the 
> entire OS, all the processes and kernel  are written in Swift (might be 
> distant future, but Swift is heading that way, isn't it?).
> 
> In such case if each for-loop takes a few extra instruction, then - again - 
> yes, it matters. I know we're not talking about all for-loops, just those 
> filtering the sequence - which seems not that common of a case - but my point 
> is valid, that Swift should provide easily-reachable means to be a "good 
> citizen". Removing it will lead developers to use .filter(_:) instead, in 
> order to save lines of code and additional typing.
> 
> While many searches in open source code found a minimum usage of 
> for-in-where, I think this is not due to it being confusing, but just not 
> well known, otherwise it would be used a lot more. Most developers that have 
> prior programming experience will only skim through the Language Guide 
> itself, which doesn't mention that `where` can be used in for loops (!!!), or 
> even while loops and there isn't a single example where it would be used.
> 
> Both
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html
> and the ePub download on 
> https://swift.org/documentation/#the-swift-programming-language
> 
> Maybe I'm missing something, but the language guide only mentions `where` for 
> the switch-case scenario. So the argument (which floated around here) that 
> this is not being actively used is kind of moot since how could anyone be 
> using it since it's not properly documented and no one who doesn't closely 
> watch release notes can possibly know about this.

Non-argument... everything that has been removed was documented prior to its 
removal.

> 
> 
>> 
>> As for the '
>> 
>>> 
>>> I've previously noted that if/guard-continue come in really close 
>>> speed-wise, which makes them candidates for a fix-it in case `where` is 
>>> indeed removed.
>>> 
>>> My response here was solely to Jean-Daniel's note that he mustn't forget to 
>>> include the lazy accessor, pointing out that even the lazy accessor is 
>>> slower than using an inline check.
>>> 
>>> 
 
 -- 
 Brent Royal-Gordon
 Architechies
 
>>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

Regards
(From mobile)

> On Jun 14, 2016, at 7:01 AM, Charlie Monroe  wrote:
> 
> 
>> On Jun 13, 2016, at 9:59 PM, Brent Royal-Gordon  
>> wrote:
>> 
 See the benchmarks me and Erica have posted here a few days back - even 
 with the lazy accessor, if you decided to use filter(_:), you lost 10+% of 
 performance. Correct way to do this without `where` and without 
 performance penalization is to use guard within the for-in loop.
>>> 
>>> 10% on a microbenchmark repeater 400 times is hardly a justification 
>>> for going on way or the other.
>> 
>> You're right: 10% on a microbenchmark isn't the best possible data. If you 
>> have better data, we are all ears.
> 
> I never said that it's a deal-breaker, but it is definitely something to 
> consider. Since we're discussing performance of the loop itself, you can't 
> perform much in the body of the for loop since it would skew the result 
> (obviously). 

This is a potentially very questionable statement as it stands!  Rule #1 of 
micro benchmarking is: they measure something for sure, but do you know what? 
Unless you do understand your compiler and how to make it do what you want, 
micro-benchmarks should always be assumed to be a misleading waste of time. If 
however you manage to convince yourself that what you measure is what your 
think you are measuring, then they can be a useful tool (disassembling is a 
good starting point).

Benchmarks like that should be considered wit their use-case. The numbers 
(provided they can be validated) would indicate that the difference is 
negligeable altogether. And someone doing heavy math would hopefully use 
accelerate for vectorization, rather than code like this.

> 
> I've previously noted that if/guard-continue come in really close speed-wise, 
> which makes them candidates for a fix-it in case `where` is indeed removed.
> 
> My response here was solely to Jean-Daniel's note that he mustn't forget to 
> include the lazy accessor, pointing out that even the lazy accessor is slower 
> than using an inline check.
> 
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

The performance of stdlib methods is not fixed in stone.

And a language feature being undocumented wouldn't explain why the entire
stdlib uses it only three times :)
On Tue, Jun 14, 2016 at 1:42 AM Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> I used to do low latency java for trading systems... the kind of coding
> where we would go out of our way to avoid ANY intraday gc activity (yes it
> can be done, even for parsing xml files). So we cared about a lot of
> things... But when you look at the numbers above on a 4_000_000 iterations
> loop and say the differential matters? I say you are probably using the
> wrong tools to write your code in the first place, and you should be using
> accelerate.
>
>
> Yes, I say it does matter. Of course, 4 million iterations is a fictional
> example that rarely occurrs on its own, but gives you an idea that there's
> more going on behind the scenes other than pure iteration.
>
> You're looking at it from a point where one app does one thing and the
> loop will have just a few iterations. Try to look at it from a point where
> the entire OS, all the processes and kernel  are written in Swift (might be
> distant future, but Swift is heading that way, isn't it?).
>
> In such case if each for-loop takes a few extra instruction, then - again
> - yes, it matters. I know we're not talking about all for-loops, just those
> filtering the sequence - which seems not that common of a case - but my
> point is valid, that Swift should provide easily-reachable means to be a
> "good citizen". Removing it will lead developers to use .filter(_:)
> instead, in order to save lines of code and additional typing.
>
> While many searches in open source code found a minimum usage of
> for-in-where, I think this is not due to it being confusing, but just not
> well known, otherwise it would be used a lot more. Most developers that
> have prior programming experience will only skim through the Language Guide
> itself, which doesn't mention that `where` can be used in for loops (!!!),
> or even while loops and there isn't a single example where it would be used.
>
> Both
>
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html
> and the ePub download on
> https://swift.org/documentation/#the-swift-programming-language
>
> Maybe I'm missing something, but the language guide only mentions `where`
> for the switch-case scenario. So the argument (which floated around here)
> that this is not being actively used is kind of moot since how could anyone
> be using it since it's not properly documented and no one who doesn't
> closely watch release notes can possibly know about this.
>
>
>
> As for the '
>
>
> I've previously noted that if/guard-continue come in really close
> speed-wise, which makes them candidates for a fix-it in case `where` is
> indeed removed.
>
> My response here was solely to Jean-Daniel's note that he mustn't forget
> to include the lazy accessor, pointing out that even the lazy accessor is
> slower than using an inline check.
>
>
>
> --
>
> Brent Royal-Gordon
>
> Architechies
>
>
>
> ___
> 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

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

[Charlie Monroe via swift-evolution]

> I used to do low latency java for trading systems... the kind of coding where 
> we would go out of our way to avoid ANY intraday gc activity (yes it can be 
> done, even for parsing xml files). So we cared about a lot of things... But 
> when you look at the numbers above on a 4_000_000 iterations loop and say the 
> differential matters? I say you are probably using the wrong tools to write 
> your code in the first place, and you should be using accelerate.

Yes, I say it does matter. Of course, 4 million iterations is a fictional 
example that rarely occurrs on its own, but gives you an idea that there's more 
going on behind the scenes other than pure iteration.

You're looking at it from a point where one app does one thing and the loop 
will have just a few iterations. Try to look at it from a point where the 
entire OS, all the processes and kernel  are written in Swift (might be distant 
future, but Swift is heading that way, isn't it?).

In such case if each for-loop takes a few extra instruction, then - again - 
yes, it matters. I know we're not talking about all for-loops, just those 
filtering the sequence - which seems not that common of a case - but my point 
is valid, that Swift should provide easily-reachable means to be a "good 
citizen". Removing it will lead developers to use .filter(_:) instead, in order 
to save lines of code and additional typing.

While many searches in open source code found a minimum usage of for-in-where, 
I think this is not due to it being confusing, but just not well known, 
otherwise it would be used a lot more. Most developers that have prior 
programming experience will only skim through the Language Guide itself, which 
doesn't mention that `where` can be used in for loops (!!!), or even while 
loops and there isn't a single example where it would be used.

Both
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html
 

and the ePub download on 
https://swift.org/documentation/#the-swift-programming-language 


Maybe I'm missing something, but the language guide only mentions `where` for 
the switch-case scenario. So the argument (which floated around here) that this 
is not being actively used is kind of moot since how could anyone be using it 
since it's not properly documented and no one who doesn't closely watch release 
notes can possibly know about this.


> 
> As for the '
> 
>> 
>> I've previously noted that if/guard-continue come in really close 
>> speed-wise, which makes them candidates for a fix-it in case `where` is 
>> indeed removed.
>> 
>> My response here was solely to Jean-Daniel's note that he mustn't forget to 
>> include the lazy accessor, pointing out that even the lazy accessor is 
>> slower than using an inline check.
>> 
>> 
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>> 

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

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

[L. Mihalkovic via swift-evolution]

> -O (Fast) 
> 
> plain for loop with guard 
> Elapsed time: 0.00411999225616455 
> plain for loop with if 
> Elapsed time: 0.00422400236129761 
> where test 
> Elapsed time: 0.00419700145721436 
> eager filter test 
> Elapsed time: 0.033439040184021 
> lazy filter test 
> Elapsed time: 0.00690501928329468 
> Program ended with exit code: 0 
> 
> Code: 
> 
> public func timetest(_ note: String, block: () -> Void) { > let date = 
> NSDate() > block() 
> let timeInterval = NSDate().timeIntervalSince(date) 
> print(note); print("Elapsed time: \(timeInterval)") 
> } 
> 
> let count = 4_000_000 > let range = 1...count 
> 
> timetest("plain for loop with guard") {
So this is what we are taking about... 


Regards
(From mobile)

> On Jun 14, 2016, at 7:01 AM, Charlie Monroe  wrote:
> 
> 
>> On Jun 13, 2016, at 9:59 PM, Brent Royal-Gordon  
>> wrote:
>> 
 See the benchmarks me and Erica have posted here a few days back - even 
 with the lazy accessor, if you decided to use filter(_:), you lost 10+% of 
 performance. Correct way to do this without `where` and without 
 performance penalization is to use guard within the for-in loop.
>>> 
>>> 10% on a microbenchmark repeater 400 times is hardly a justification 
>>> for going on way or the other.
>> 
>> You're right: 10% on a microbenchmark isn't the best possible data. If you 
>> have better data, we are all ears.
> 
> I never said that it's a deal-breaker, but it is definitely something to 
> consider. Since we're discussing performance of the loop itself, you can't 
> perform much in the body of the for loop since it would skew the result 
> (obviously). 

I used to do low latency java for trading systems... the kind of coding where 
we would go out of our way to avoid ANY intraday gc activity (yes it can be 
done, even for parsing xml files). So we cared about a lot of things... But 
when you look at the numbers above on a 4_000_000 iterations loop and say the 
differential matters? I say you are probably using the wrong tools to write 
your code in the first place, and you should be using accelerate.

As for the '

> 
> I've previously noted that if/guard-continue come in really close speed-wise, 
> which makes them candidates for a fix-it in case `where` is indeed removed.
> 
> My response here was solely to Jean-Daniel's note that he mustn't forget to 
> include the lazy accessor, pointing out that even the lazy accessor is slower 
> than using an inline check.
> 
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dany St-Amant via swift-evolution]

> Le 13 juin 2016 à 11:54, Erica Sadun via swift-evolution 
>  a écrit :
> 
> 
>> On Jun 13, 2016, at 9:44 AM, let var go via swift-evolution 
>>  wrote:
>> 
>> I think we must be reading different discussions.
>> 
>> What I have seen in this discussion is the following:
>> 
>> a) The need to filter a for-in loop doesn't arise that often; but,
>> b) When it does arise, everyone who has chimed in on this thread (except the 
>> two people who are proposing the change) thinks that the "where" clause is 
>> the clearest, most expressive way to do it.
> 
> As a point of order, may I request you stop singling out "the two people who 
> are proposing the change" and discuss the merits of the pitch rather than the 
> people involved in the discussion. Details of the Swift community code of 
> conduct can be found here: https://swift.org/community/#code-of-conduct
> 
> As syntactic sugar, the filtering syntax is rarely used, hard to discover, 
> and elevates one style (continue if false) above others (continue if false, 
> break if true, break if false), which are not expressible using similar 
> shorthand. It introduces a fluent style that discourages design comments at 
> the point of use and can be difficult to breakpoint during debugging. The 
> recommended alternative (using a separate guard) addresses all these points: 
> better commenting, better breakpointing and debugging, and fully covers the 
> domain of filtering and early exiting.

Another point about the narrowness of 'where' beside being only for one of the 
four true/false continue/break cases, is that it only handle conditions at the 
top of the loop. Any 'continue' required in the middle of the block (after some 
processing) has to be handle by the "more powerful/versatile" 'guard' and/or 
'if'.

Also if the need arise to do something extra beside 'continue' on the rejects, 
even something as simple as logging to the console, the 'where' needs to be 
converted to a 'guard' or 'if'. 

Beside these drawbacks, I still think 'where' is nice to have

Dany

> In response, I'd like to hear why "continue if false" should be prioritized 
> above the other options and should be retained, or alternatively why the 
> suite should be completed (as in the original discussion with "while") in 
> preference to the advantages accrued by guard.
> 
> Thank you,
> 
> -- Erica
> ___
> 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

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

[Xiaodi Wu via swift-evolution]

Not the only, actually, but close. There's still `case ... where` and
`catch ... where`; this proposal offers some suggestions on that.


On Mon, Jun 13, 2016 at 4:16 PM, Антон Жилин  wrote:

> Ah, I see. Then for-each will be the only usage of `where`, aside from
> generics. I'm even more in favour of the proposal being discussed, then.
>
> - Anton
>
> 2016-06-13 23:03 GMT+03:00 Brent Royal-Gordon :
>
>> > Also, we should think about removing `where` from `while` loops.
>> > We can copy `if` syntax to `while` conditions.
>>
>> SE-0099 applies to all constructs which use condition clauses, including
>> `while`. The "Detailed Design" section even specifically mentions the
>> `while` grammar rule. <
>> https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md#detailed-design
>> >
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 4:36 PM, let var go  wrote:

>
>
> On Mon, Jun 13, 2016 at 12:21 PM Xiaodi Wu  wrote:
>
>> On Mon, Jun 13, 2016 at 12:20 PM, let var go  wrote:
>>
>>>
>>>
>>> On Mon, Jun 13, 2016 at 9:46 AM Xiaodi Wu  wrote:
>>>
 On Mon, Jun 13, 2016 at 11:41 AM, let var go 
 wrote:

>
>
> On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu  wrote:
>
>> Moreover, I should add, if your goal is to eliminate the possibility
>> of continuing and breaking from inside the loop, `.forEach()` does that
>> exactly, so your argument would be for the elimination of `for..in`
>> altogether.
>>
>
> I have no "goal" of eliminating the possibility of continuing or
> breaking from inside the loop. In general, it is not my goal to try and
> control how other people code their programs at all. I don't want to tell
> you that you can't 'continue' if you want to 'continue.'
>
> *I am not trying to make everyone adopt my own personal coding style
> and/or philosophy.*
>

 We're not discussing style.

>>>
>>> Yes, we are discussing style, and for a very simple reason: Style is
>>> essential to readability and clarity.
>>>
>>> When we talk about for...in...where vs. guard...continue, all we are
>>> talking about is style. In terms of functionality, they do exactly the same
>>> thing. In terms of style, however, *one is easier to read than the
>>> other. *
>>>
>>> Some people think that guard...continue is easier to read and
>>> understand. Others, like me, think that for...in...where is easier to read
>>> and understand. *But that is a disagreement over style, not
>>> functionality*.
>>>
>>> And here is the difficult thing about debates like this: Both sides are
>>> right. What I consider to be the clearest, most readable style of coding
>>> may be confusing to someone else, and vice versa. Different people find
>>> different styles confusing. Not everyone learns the same way. Not everyone
>>> reads the same way. Not everyone codes the same way. What is hard for me to
>>> understand may be easy for you to understand.
>>>
>>> So if using 'continue' inside your for...in loops makes sense to you,
>>> and it helps you understand your own code, then go for it. It's not my
>>> style, not because it is "unfashionable", but because it has the opposite
>>> effect on me - it makes the code harder for me to understand.
>>>
>>
>> You misunderstand me. I am not supporting this proposal because I think
>> `guard` is superior style. I am supporting it because I have come to the
>> conclusion that `where` is harmful. I do happen to think that `guard` is a
>> superior style, but that's not the motivation for removing `where`, nor
>> could it be a justification.
>>
>
> No, I didn't misunderstand you. You are talking about style, even if you
> don't realize it. Examine these two pieces of code:
>
> Example 1:
> for x in xs where x < 10 {
> print(x)
> }
>
> Example 2:
> for x in xs {
> guard x < 10 else { continue }
> print(x)
> }
>
> Example 1 and Example 2 are functionally equivalent. They do exactly the
> same thing. They will produce exactly the same output. *They only differ
> with regard to style.*
>
> You think that Example 2 is a better style than Example 1 because you
> think that Example 1 is confusing to new programmers. You argue that the
> confusion is harmful.
>

If you define 'style' as the difference between any two things that produce
the same output, then indeed all language design is 'style.' Writing in
Lisp vs. writing in C++ would be a choice of 'style.' When you say that
Swift should accommodate your own 'style,' then, that could just as well be
an argument for Lisp-like syntax. This is not, however, what people
generally understand to be 'coding style.'

The fact is that there are even experienced users of Swift who see `where`
and affirmatively believe it does what it does not do. The same cannot be
said for `guard`. That is, a user might say, 'What in the world does guard
mean?', but even a totally new user is unlikely to say, 'I can guess what
guard means, and it means [something that guard does not in fact mean].'
That is not at all an argument about style. And yes, I argue that confusion
is harmful.

I think that Example 1 is a better style than Example 2 because I think
> that it is easier to read and expresses my intent with greater clarity.
> Whatever cognitive burden is placed on the new programmer to learn about
> the 'where' clause is extremely modest and more than made up for by the
> ability to express their intentions in a way that is both concise and
> readable. Example 2, by contrast, looks cluttered and splits the
> control-flow logic into two parts creating a cognitive burden that I
> consider harmful.
>

You are stretching here; `guard` imposes a 'harmful cognitive burden'?
Again, 

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

[let var go via swift-evolution]

On Mon, Jun 13, 2016 at 12:21 PM Xiaodi Wu  wrote:

> On Mon, Jun 13, 2016 at 12:20 PM, let var go  wrote:
>
>>
>>
>> On Mon, Jun 13, 2016 at 9:46 AM Xiaodi Wu  wrote:
>>
>>> On Mon, Jun 13, 2016 at 11:41 AM, let var go  wrote:
>>>


 On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu  wrote:

> Moreover, I should add, if your goal is to eliminate the possibility
> of continuing and breaking from inside the loop, `.forEach()` does that
> exactly, so your argument would be for the elimination of `for..in`
> altogether.
>

 I have no "goal" of eliminating the possibility of continuing or
 breaking from inside the loop. In general, it is not my goal to try and
 control how other people code their programs at all. I don't want to tell
 you that you can't 'continue' if you want to 'continue.'

 *I am not trying to make everyone adopt my own personal coding style
 and/or philosophy.*

>>>
>>> We're not discussing style.
>>>
>>
>> Yes, we are discussing style, and for a very simple reason: Style is
>> essential to readability and clarity.
>>
>> When we talk about for...in...where vs. guard...continue, all we are
>> talking about is style. In terms of functionality, they do exactly the same
>> thing. In terms of style, however, *one is easier to read than the
>> other. *
>>
>> Some people think that guard...continue is easier to read and understand.
>> Others, like me, think that for...in...where is easier to read and
>> understand. *But that is a disagreement over style, not functionality*.
>>
>> And here is the difficult thing about debates like this: Both sides are
>> right. What I consider to be the clearest, most readable style of coding
>> may be confusing to someone else, and vice versa. Different people find
>> different styles confusing. Not everyone learns the same way. Not everyone
>> reads the same way. Not everyone codes the same way. What is hard for me to
>> understand may be easy for you to understand.
>>
>> So if using 'continue' inside your for...in loops makes sense to you, and
>> it helps you understand your own code, then go for it. It's not my style,
>> not because it is "unfashionable", but because it has the opposite effect
>> on me - it makes the code harder for me to understand.
>>
>
> You misunderstand me. I am not supporting this proposal because I think
> `guard` is superior style. I am supporting it because I have come to the
> conclusion that `where` is harmful. I do happen to think that `guard` is a
> superior style, but that's not the motivation for removing `where`, nor
> could it be a justification.
>

No, I didn't misunderstand you. You are talking about style, even if you
don't realize it. Examine these two pieces of code:

Example 1:
for x in xs where x < 10 {
print(x)
}

Example 2:
for x in xs {
guard x < 10 else { continue }
print(x)
}

Example 1 and Example 2 are functionally equivalent. They do exactly the
same thing. They will produce exactly the same output. *They only differ
with regard to style.*

You think that Example 2 is a better style than Example 1 because you think
that Example 1 is confusing to new programmers. You argue that the
confusion is harmful.

I think that Example 1 is a better style than Example 2 because I think
that it is easier to read and expresses my intent with greater clarity.
Whatever cognitive burden is placed on the new programmer to learn about
the 'where' clause is extremely modest and more than made up for by the
ability to express their intentions in a way that is both concise and
readable. Example 2, by contrast, looks cluttered and splits the
control-flow logic into two parts creating a cognitive burden that I
consider harmful.

These are debates about style, and that is okay, because style is about
clarity, readability, and expressiveness, all of which are essential
goals. *Style
is substance*. Half the battle is getting the computer to follow the
correct instructions. The other half is making the code readable so that
human beings can understand it - and that is a matter of style.

There are times where I will choose to use a 'continue' statement inside a
for...in loop. The reason hardly ever has anything to do with functionality
- I could design the code differently to avoid that particular code smell
if I put my mind to it. No, I would choose the 'continue' statement because
in that particular context it makes my code more accessible to human beings
(including myself, later on). The ability to choose one solution over
another for purely stylistic reasons means that I can maximize both the
functionality and the readability of my code.

This proposal prevents the programmer from writing the best possible code
because it disallows a stylistic choice that improves readability. I don't
like that. It means that I have to write code that is worse than it has to

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

[Антон Жилин via swift-evolution]

Ah, I see. Then for-each will be the only usage of `where`, aside from
generics. I'm even more in favour of the proposal being discussed, then.

- Anton

2016-06-13 23:03 GMT+03:00 Brent Royal-Gordon :

> > Also, we should think about removing `where` from `while` loops.
> > We can copy `if` syntax to `while` conditions.
>
> SE-0099 applies to all constructs which use condition clauses, including
> `while`. The "Detailed Design" section even specifically mentions the
> `while` grammar rule. <
> https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md#detailed-design
> >
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> Also, we should think about removing `where` from `while` loops.
> We can copy `if` syntax to `while` conditions.

SE-0099 applies to all constructs which use condition clauses, including 
`while`. The "Detailed Design" section even specifically mentions the `while` 
grammar rule. 


-- 
Brent Royal-Gordon
Architechies

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

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

[Brent Royal-Gordon via swift-evolution]

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

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

-- 
Brent Royal-Gordon
Architechies

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

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 12:20 PM, let var go  wrote:

>
>
> On Mon, Jun 13, 2016 at 9:46 AM Xiaodi Wu  wrote:
>
>> On Mon, Jun 13, 2016 at 11:41 AM, let var go  wrote:
>>
>>>
>>>
>>> On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu  wrote:
>>>
 Moreover, I should add, if your goal is to eliminate the possibility of
 continuing and breaking from inside the loop, `.forEach()` does that
 exactly, so your argument would be for the elimination of `for..in`
 altogether.

>>>
>>> I have no "goal" of eliminating the possibility of continuing or
>>> breaking from inside the loop. In general, it is not my goal to try and
>>> control how other people code their programs at all. I don't want to tell
>>> you that you can't 'continue' if you want to 'continue.'
>>>
>>> *I am not trying to make everyone adopt my own personal coding style
>>> and/or philosophy.*
>>>
>>
>> We're not discussing style.
>>
>
> Yes, we are discussing style, and for a very simple reason: Style is
> essential to readability and clarity.
>
> When we talk about for...in...where vs. guard...continue, all we are
> talking about is style. In terms of functionality, they do exactly the same
> thing. In terms of style, however, *one is easier to read than the
> other. *
>
> Some people think that guard...continue is easier to read and understand.
> Others, like me, think that for...in...where is easier to read and
> understand. *But that is a disagreement over style, not functionality*.
>
> And here is the difficult thing about debates like this: Both sides are
> right. What I consider to be the clearest, most readable style of coding
> may be confusing to someone else, and vice versa. Different people find
> different styles confusing. Not everyone learns the same way. Not everyone
> reads the same way. Not everyone codes the same way. What is hard for me to
> understand may be easy for you to understand.
>
> So if using 'continue' inside your for...in loops makes sense to you, and
> it helps you understand your own code, then go for it. It's not my style,
> not because it is "unfashionable", but because it has the opposite effect
> on me - it makes the code harder for me to understand.
>

You misunderstand me. I am not supporting this proposal because I think
`guard` is superior style. I am supporting it because I have come to the
conclusion that `where` is harmful. I do happen to think that `guard` is a
superior style, but that's not the motivation for removing `where`, nor
could it be a justification.


> You made a very strong claim: use of `guard...continue` leads to 'smelly'
>> code, or in other words bad code. In other words, you claim that
>> `guard...continue` is harmful. That is grounds for removal, and if you
>> believe it to be true, I encourage you to propose it to the list and get
>> feedback on that opinion.
>>
>> If you're saying that you simply don't prefer it for reasons of 'style,'
>> again I emphasize that the topic at hand here is not about personal coding
>> style. The claim we are making is that `where` is harmful. I too like it
>> for style, and I'll be sad to see it go. But I have concluded that it must
>> go.
>>
>>
>>> There is also a big difference between 'break' and 'continue'. I am not
>>> afraid to use 'break', and I don't consider it a code smell. It allows for
>>> early exit from a loop based on conditions that are not always known at the
>>> time the loop is entered. for...in loops are necessary precisely because
>>> they allow for the early exit.
>>>
>>> You don't need for...in if you want to continue - you can use forEach
>>> for that. Instead of using 'continue', you just use 'return' without doing
>>> anything and it moves on to the next iteration. So really, the only purpose
>>> that for...in serves that is not served by forEach is early exit. But
>>> regardless, *even if for...in served no additional purpose that
>>> couldn't be served by forEach, I would keep it in the language because
>>> there are situations where I believe it is easier to read, and
>>> expressiveness and clarity are important to me.*
>>>
>>>

 On Mon, Jun 13, 2016 at 10:55 Xiaodi Wu  wrote:

> On Mon, Jun 13, 2016 at 10:44 AM, let var go 
> wrote:
>
>> I think we must be reading different discussions.
>>
>> What I have seen in this discussion is the following:
>>
>> a) The need to filter a for-in loop doesn't arise that often; but,
>> b) When it does arise, everyone who has chimed in on this thread
>> (except the two people who are proposing the change) thinks that the
>> "where" clause is the clearest, most expressive way to do it.
>>
>> Something that would help me get on board with this change is more
>> evidence about what kind of problems it is actually creating.
>>
>> As best I can tell, this proposal got started because 

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

[let var go via swift-evolution]

On Mon, Jun 13, 2016 at 8:54 AM Erica Sadun  wrote:

>
> On Jun 13, 2016, at 9:44 AM, let var go via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think we must be reading different discussions.
>
> What I have seen in this discussion is the following:
>
> a) The need to filter a for-in loop doesn't arise that often; but,
> b) When it does arise, everyone who has chimed in on this thread (except
> the two people who are proposing the change) thinks that the "where" clause
> is the clearest, most expressive way to do it.
>
>
> As a point of order, may I request you stop singling out "the two people
> who are proposing the change" and discuss the merits of the pitch rather
> than the people involved in the discussion. Details of the Swift community
> code of conduct can be found here:
> https://swift.org/community/#code-of-conduct
>
> As syntactic sugar, the filtering syntax is rarely used, hard to discover,
> and elevates one style (continue if false) above others (continue if false,
> break if true, break if false), which are not expressible using similar
> shorthand. It introduces a fluent style that discourages design comments at
> the point of use and can be difficult to breakpoint during debugging. The
> recommended alternative (using a separate guard) addresses all these
> points: better commenting, better breakpointing and debugging, and fully
> covers the domain of filtering and early exiting.
>
> In response, I'd like to hear why "continue if false" should be
> prioritized above the other options and should be retained, or
> alternatively why the suite should be completed (as in the original
> discussion with "while") in preference to the advantages accrued by guard.
>

The way you broke it down into the four different categories was helpful to
me - I hadn't thought of it that way before. Here's may take on it:


   - "continue if false"
   - This is the current 'where` keyword.
   - "continue if true"
  - This is the inverse of the current 'where' option. Because it is
  the inverse, it doesn't need a separate keyword. You just add the logical
  not '!' to the predicate, or just reverse the test, to obtain the inverse
  filtering operation.
  - So, for example, `for string in strings where
  string.hasPrefix("somePrefix")` becomes `for string in strings where
  !string.hasPrefix("somePrefix")`; or `for x in xs where x < 5`, becomes
  `for x in xs where x >= 5`
  - Using a single keyword but reversing the predicate isn't the only
  approach but it has the advantage of not polluting the language with
  unnecessary keywords where a single keyword can do the job.
   - "break if false"
  - In this scenario, you start looping through a collection, but exit
  early when some condition is no longer true. It combines a for...in loop
  with a 'while' loop.
  - This construct would allow you to set a condition for early exit
  from the loop. The problem I see with this is that when I need to exit a
  loop early, I usually need to do something else first, like
assign a value
  to a variable, or take some other action. So for example, I might do
  something like this:

var nextEvent: Event?
for event in events {
if event.time >= now  {
nextEvent = event
break
}
}

   - The point is that before I could use 'break', I had to take some
  action (assign a value to nextEvent). So just defining an early exit
  condition wouldn't really work. I'm trying to think of a use-case where I
  would want to exit early without doing anything first, and I can't. Given
  the appropriate use case, however, I could see a place for a keyword that
  did this like 'until', or 'while'. Until then, though, I
wouldn't create a
  keyword for something that doesn't have a common use. Filtering with
  'where' is at least used sometimes, even if it isn't the most common
  pattern on the planet.
   - "break if true"
  - I would apply the same arguments in "break if false"

So I would say that "continue if false" and "continue if true" are
accomplished using the same keyword, and "break if false" and "break if
true" don't have demonstrated use cases that can be solved with a
keyword/predicate combination - early exit usually requires some additional
action other than just exiting which couldn't be easily baked into the
keyword.


>
> Thank you,
>
> -- Erica
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

I would say we need a separate meeting where we propose to add them and discuss 
why we would want them in Swift :).

Sent from my iPhone

> On 13 Jun 2016, at 16:26, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution 
>>  wrote:
>> 
>> I am 100% with Charlie on this. Expressiveness has to do with the 
>> *effectiveness* of conveying a thought or a feeling.
>> 
>> Keep "where". It is expressive. It conveys a specific idea effectively and 
>> concisely.
> 
> For those of you in favor of retaining `where`, how do you feel about adding 
> `while`, `until`, `unless`, etc?
> 
> -- E
> 
> ___
> 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

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

[Vladimir.S via swift-evolution]

Suport Haravikk's opinion, just wanted to add:

> Besides, the main argument for it being confusing comes from its use in 
both while and for loops,


The other main argument was that it is not clear (for some beginners, who 
never see simple SELECT * FROM .. WHERE .. clause and don't want to check 
in Swift documentation or in playground) if `where` in for-in loop means 
'continue if false' or 'break if false". In this case I believe we can 
discuss if 'where' should be renamed to something more obvious. But not to 
remove the feature because of this.


On 13.06.2016 20:24, Haravikk via swift-evolution wrote:



On 13 Jun 2016, at 13:28, Xiaodi Wu via swift-evolution 
 wrote:

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


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

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

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

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

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

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

[let var go via swift-evolution]

On Mon, Jun 13, 2016 at 8:26 AM Erica Sadun  wrote:

>
> > On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I am 100% with Charlie on this. Expressiveness has to do with the
> *effectiveness* of conveying a thought or a feeling.
> >
> > Keep "where". It is expressive. It conveys a specific idea effectively
> and concisely.
>
> For those of you in favor of retaining `where`, how do you feel about
> adding `while`, `until`, `unless`, etc?
>
> -- E
>
>
That would be interesting...I assume that 'while' or 'until' would cause
early exit from the loop, and 'unless' would be the logical inverse of
'where'.

I'd have to think about it some more, but my instinct is that I would be in
favor of adding 'unless' as the logical inverse of 'where' (exclude items
based on the predicate, instead of include items based on the predicate). I
wouldn't add 'while' or 'until', because we already have conditional loops
like the 'while' loop to serve that need.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 12:24 PM, Haravikk 
wrote:

>
> > On 13 Jun 2016, at 13:28, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I think this discussion has made it pretty plain that what is claimed to
> be 'so useful' is barely ever used. Moreover, it provides no independent
> uses. The point of these pitches is to sound out arguments, not, as far as
> I was aware, to take a vote.
>
> I think that the discussion has made it clear that far more people want
> this feature to remain, and feel it is a valid part of the language,
> whether or not it’s a mainly aesthetic one, and that it should stay.
> Whether or not the discussion is intended as a vote is irrelevant, if more
> people want a feature to remain than want it removed then that suggests the
> justification for removing it had better be a really good one.
>
> So far we have redundancy, which isn’t really sufficient reason to remove
> something, as we have plenty of redundant syntax for convenience. Take
> conditional binding for example, which is essentially just a shorthand for
> pattern matching. Functionally they’re identical, and there’s not much
> difference in complexity (you don’t have to learn the pattern matching
> aspect in order to use it for unwrapping optionals), so really it’s just a
> neat shorthand similar to where, and could be removed easily, yet people
> would fight against it just as furiously.
>
> Otherwise the argument is against confusion/mistakes, but this alone isn’t
> a reason to remove a feature vs addressing why confusion is caused.
> Besides, the main argument for it being confusing comes from its use in
> both while and for loops, but if it’s being removed from while loops then
> this ceases to be an issue. As a result it would be premature to remove the
> feature as we don’t know yet if it’s still confusing when only permitted on
> for loops.
>
> After that the other issue is whether filtering deserves a special case,
> but this is muddied by a lack of use largely resulting from lack of
> awareness. For us to get useful evidence either way would require this to
> put more widely known and to see if it continues to be used infrequently; I
> know about the keyword and use it in maybe 20% of my for loops (plus I
> actually rarely use while loops, and mainly in testing).
> Besides which there is a proposal for a variant of where (while/until)
> which gives access to another fairly common variant of if/guard that
> developers may wish to replace, which would address a lack of versatility.
>
> The benefit of the where clause is eliminating a line by putting the same
> condition on the opening loop, you may not consider this worthwhile but
> clearly plenty of people do,


It's not that I don't consider it worthwhile. I consider it *harmful*
because it leaves implicit the key question of what happens when `where` is
not fulfilled.


> therefore I’d consider this justification enough for the feature to remain
> as we find it useful and prefer how our code looks with this shorthand. You
> remain free as ever to not use it.


Otherwise, I think you sum up the arguments that have been laid out pretty
well. All in all, I believe we've made a case that's stronger than the one
that was made for the for;; loop. At this point, I think there's little
left to discuss prior to a formal review.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 13 Jun 2016, at 13:28, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I think this discussion has made it pretty plain that what is claimed to be 
> 'so useful' is barely ever used. Moreover, it provides no independent uses. 
> The point of these pitches is to sound out arguments, not, as far as I was 
> aware, to take a vote.

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

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

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

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

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

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

[let var go via swift-evolution]

On Mon, Jun 13, 2016 at 9:46 AM Xiaodi Wu  wrote:

> On Mon, Jun 13, 2016 at 11:41 AM, let var go  wrote:
>
>>
>>
>> On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu  wrote:
>>
>>> Moreover, I should add, if your goal is to eliminate the possibility of
>>> continuing and breaking from inside the loop, `.forEach()` does that
>>> exactly, so your argument would be for the elimination of `for..in`
>>> altogether.
>>>
>>
>> I have no "goal" of eliminating the possibility of continuing or breaking
>> from inside the loop. In general, it is not my goal to try and control how
>> other people code their programs at all. I don't want to tell you that you
>> can't 'continue' if you want to 'continue.'
>>
>> *I am not trying to make everyone adopt my own personal coding style
>> and/or philosophy.*
>>
>
> We're not discussing style.
>

Yes, we are discussing style, and for a very simple reason: Style is
essential to readability and clarity.

When we talk about for...in...where vs. guard...continue, all we are
talking about is style. In terms of functionality, they do exactly the same
thing. In terms of style, however, *one is easier to read than the other. *

Some people think that guard...continue is easier to read and understand.
Others, like me, think that for...in...where is easier to read and
understand. *But that is a disagreement over style, not functionality*.

And here is the difficult thing about debates like this: Both sides are
right. What I consider to be the clearest, most readable style of coding
may be confusing to someone else, and vice versa. Different people find
different styles confusing. Not everyone learns the same way. Not everyone
reads the same way. Not everyone codes the same way. What is hard for me to
understand may be easy for you to understand.

So if using 'continue' inside your for...in loops makes sense to you, and
it helps you understand your own code, then go for it. It's not my style,
not because it is "unfashionable", but because it has the opposite effect
on me - it makes the code harder for me to understand.




> You made a very strong claim: use of `guard...continue` leads to 'smelly'
> code, or in other words bad code. In other words, you claim that
> `guard...continue` is harmful. That is grounds for removal, and if you
> believe it to be true, I encourage you to propose it to the list and get
> feedback on that opinion.
>
> If you're saying that you simply don't prefer it for reasons of 'style,'
> again I emphasize that the topic at hand here is not about personal coding
> style. The claim we are making is that `where` is harmful. I too like it
> for style, and I'll be sad to see it go. But I have concluded that it must
> go.
>
>
>> There is also a big difference between 'break' and 'continue'. I am not
>> afraid to use 'break', and I don't consider it a code smell. It allows for
>> early exit from a loop based on conditions that are not always known at the
>> time the loop is entered. for...in loops are necessary precisely because
>> they allow for the early exit.
>>
>> You don't need for...in if you want to continue - you can use forEach for
>> that. Instead of using 'continue', you just use 'return' without doing
>> anything and it moves on to the next iteration. So really, the only purpose
>> that for...in serves that is not served by forEach is early exit. But
>> regardless, *even if for...in served no additional purpose that couldn't
>> be served by forEach, I would keep it in the language because there are
>> situations where I believe it is easier to read, and expressiveness and
>> clarity are important to me.*
>>
>>
>>>
>>> On Mon, Jun 13, 2016 at 10:55 Xiaodi Wu  wrote:
>>>
 On Mon, Jun 13, 2016 at 10:44 AM, let var go 
 wrote:

> I think we must be reading different discussions.
>
> What I have seen in this discussion is the following:
>
> a) The need to filter a for-in loop doesn't arise that often; but,
> b) When it does arise, everyone who has chimed in on this thread
> (except the two people who are proposing the change) thinks that the
> "where" clause is the clearest, most expressive way to do it.
>
> Something that would help me get on board with this change is more
> evidence about what kind of problems it is actually creating.
>
> As best I can tell, this proposal got started because "somewhere" some
> new programmers (no one knows how many) expressed some confusion (no one
> knows how seriously they were confused, or how long it took them to figure
> it out) about how the where clause worked in a for-in loop. For all we
> know, once they learned the way it works, they may have said, "Hey that's
> cool! I'm gonna use that from now on!"
>
> In other words, you seem to be talking about removing a feature that
> is liked by *a lot* people, based on some 

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 12:01 PM, let var go  wrote:

> Well, the "harmful" nature of it is something that still hasn't been
> established as far as I'm concerned. I came to this discussion a little
> late, but after reading through as many old email comments as I could find,
> the only harm is an undocumented report that somewhere there were some
> relatively new users to Swift who had to ask a question about how
> for-in-where worked. If you have more information about how widespread this
> problem is and how much trouble it is really causing in the world, then
> please provide it.
>

Shawn Erickson gave a pretty compelling account on June 8. I can't tell you
how widespread it is in the world, since existence of the feature itself
does not seem to be widely known. I can tell you that the working of the
`where` clause was thought to be confusing enough that it's explicitly
called out in _Advanced Swift_, hardly a text addressed to new users. Thus,
this proposal. If the core team, with their perspective on internal and
external users, agrees that this is a problem, then it'll go. If not, then
it'll stay.


>
> On Mon, Jun 13, 2016 at 9:50 AM let var go  wrote:
>
>> No, the key difference between for...in and forEach is that for...in
>> allows for early exit. They both allow you to 'continue', though in forEach
>> it is called 'return':
>>
>> // This prints odd numbers, skipping ("continuing") past the even numbers:
>> (0..<100).forEach { if $0 % 2 == 0 { return } else { print($0) } }
>>
>> Early-exit ('break') is a different beast and requires a for...in loop.
>>
>> You missed my main point. In some situations even 'continue' may prove to
>> be useful. It is not my preferred method.
>>
>> Why do you say, "Swift is not a live-and-let-live language?" Where do you
>> get that from? Are you really saying that there is not room in the Swift
>> community for people with different coding styles and preferences? I truly
>> believe that that attitude will be very harmful to the long term future of
>> the language.
>>
>> On Mon, Jun 13, 2016 at 9:29 AM Xiaodi Wu  wrote:
>>
>>> See, the key difference between for...in and .forEach() is that one
>>> allows for continue and break and the other doesn't. Swift is not a
>>> live-and-let-live language: if you truly believe that using continue leads
>>> to bad code, then propose its removal or the removal of for...in altogether.
>>>
>>> On Mon, Jun 13, 2016 at 11:21 let var go  wrote:
>>>
 No, I wouldn't eliminate 'continue'. Even though I consider it a
 sub-optimal solution, I would keep it in the language. Why? A couple of
 reasons:

 1) I don't like it, but even 'continue' may be the best available
 solution in the context of a particular problem. I will look for other
 options first, but I don't rule out the possibility that there might come a
 time when it is the right tool for the job.

 2) Some people like it. Not everyone feels the same way about it as me.
 Some of the people who like it are better programmers than me. I have a lot
 to learn, and someday I might discover that I love 'continue' after all.
 Until then, live-and-let-live is what I say. Everyone should control their
 own flow :) Keep your hands off my 'where' and I'll keep my hands off your
 'continue' :)

 On Mon, Jun 13, 2016 at 8:56 AM Xiaodi Wu  wrote:

> On Mon, Jun 13, 2016 at 10:44 AM, let var go 
> wrote:
>
>> I think we must be reading different discussions.
>>
>> What I have seen in this discussion is the following:
>>
>> a) The need to filter a for-in loop doesn't arise that often; but,
>> b) When it does arise, everyone who has chimed in on this thread
>> (except the two people who are proposing the change) thinks that the
>> "where" clause is the clearest, most expressive way to do it.
>>
>> Something that would help me get on board with this change is more
>> evidence about what kind of problems it is actually creating.
>>
>> As best I can tell, this proposal got started because "somewhere"
>> some new programmers (no one knows how many) expressed some confusion (no
>> one knows how seriously they were confused, or how long it took them to
>> figure it out) about how the where clause worked in a for-in loop. For 
>> all
>> we know, once they learned the way it works, they may have said, "Hey
>> that's cool! I'm gonna use that from now on!"
>>
>> In other words, you seem to be talking about removing a feature that
>> is liked by *a lot* people, based on some unsubstantiated reports of user
>> error that may or may not have been totally unsubstantial.
>>
>> I don't want new programmers to be confused, either, but the "where"
>> clause is such a basic programming construct - the keyword 

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

[let var go via swift-evolution]

Well, the "harmful" nature of it is something that still hasn't been
established as far as I'm concerned. I came to this discussion a little
late, but after reading through as many old email comments as I could find,
the only harm is an undocumented report that somewhere there were some
relatively new users to Swift who had to ask a question about how
for-in-where worked. If you have more information about how widespread this
problem is and how much trouble it is really causing in the world, then
please provide it.

On Mon, Jun 13, 2016 at 9:50 AM let var go  wrote:

> No, the key difference between for...in and forEach is that for...in
> allows for early exit. They both allow you to 'continue', though in forEach
> it is called 'return':
>
> // This prints odd numbers, skipping ("continuing") past the even numbers:
> (0..<100).forEach { if $0 % 2 == 0 { return } else { print($0) } }
>
> Early-exit ('break') is a different beast and requires a for...in loop.
>
> You missed my main point. In some situations even 'continue' may prove to
> be useful. It is not my preferred method.
>
> Why do you say, "Swift is not a live-and-let-live language?" Where do you
> get that from? Are you really saying that there is not room in the Swift
> community for people with different coding styles and preferences? I truly
> believe that that attitude will be very harmful to the long term future of
> the language.
>
> On Mon, Jun 13, 2016 at 9:29 AM Xiaodi Wu  wrote:
>
>> See, the key difference between for...in and .forEach() is that one
>> allows for continue and break and the other doesn't. Swift is not a
>> live-and-let-live language: if you truly believe that using continue leads
>> to bad code, then propose its removal or the removal of for...in altogether.
>>
>> On Mon, Jun 13, 2016 at 11:21 let var go  wrote:
>>
>>> No, I wouldn't eliminate 'continue'. Even though I consider it a
>>> sub-optimal solution, I would keep it in the language. Why? A couple of
>>> reasons:
>>>
>>> 1) I don't like it, but even 'continue' may be the best available
>>> solution in the context of a particular problem. I will look for other
>>> options first, but I don't rule out the possibility that there might come a
>>> time when it is the right tool for the job.
>>>
>>> 2) Some people like it. Not everyone feels the same way about it as me.
>>> Some of the people who like it are better programmers than me. I have a lot
>>> to learn, and someday I might discover that I love 'continue' after all.
>>> Until then, live-and-let-live is what I say. Everyone should control their
>>> own flow :) Keep your hands off my 'where' and I'll keep my hands off your
>>> 'continue' :)
>>>
>>> On Mon, Jun 13, 2016 at 8:56 AM Xiaodi Wu  wrote:
>>>
 On Mon, Jun 13, 2016 at 10:44 AM, let var go 
 wrote:

> I think we must be reading different discussions.
>
> What I have seen in this discussion is the following:
>
> a) The need to filter a for-in loop doesn't arise that often; but,
> b) When it does arise, everyone who has chimed in on this thread
> (except the two people who are proposing the change) thinks that the
> "where" clause is the clearest, most expressive way to do it.
>
> Something that would help me get on board with this change is more
> evidence about what kind of problems it is actually creating.
>
> As best I can tell, this proposal got started because "somewhere" some
> new programmers (no one knows how many) expressed some confusion (no one
> knows how seriously they were confused, or how long it took them to figure
> it out) about how the where clause worked in a for-in loop. For all we
> know, once they learned the way it works, they may have said, "Hey that's
> cool! I'm gonna use that from now on!"
>
> In other words, you seem to be talking about removing a feature that
> is liked by *a lot* people, based on some unsubstantiated reports of user
> error that may or may not have been totally unsubstantial.
>
> I don't want new programmers to be confused, either, but the "where"
> clause is such a basic programming construct - the keyword is new, but the
> idea itself is as old as programming - that I don't mind expecting new
> programmers to learn how to use it. The learning curve should be 
> incredibly
> short - it is nothing more than a filter operation.
>
> There's something else here that is really important to me, though I
> don't know how others feel about it.
>
> Using the guard...continue approach that you are promoting is a code
> smell. It puts control-flow logic inside the for-in loop. That is 
> something
> I have always tried to avoid. I know that the language allows for it, but 
> I
> believe it is bad programming practice. In fact, if you get rid of the
> 

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

[let var go via swift-evolution]

No, the key difference between for...in and forEach is that for...in allows
for early exit. They both allow you to 'continue', though in forEach it is
called 'return':

// This prints odd numbers, skipping ("continuing") past the even numbers:
(0..<100).forEach { if $0 % 2 == 0 { return } else { print($0) } }

Early-exit ('break') is a different beast and requires a for...in loop.

You missed my main point. In some situations even 'continue' may prove to
be useful. It is not my preferred method.

Why do you say, "Swift is not a live-and-let-live language?" Where do you
get that from? Are you really saying that there is not room in the Swift
community for people with different coding styles and preferences? I truly
believe that that attitude will be very harmful to the long term future of
the language.

On Mon, Jun 13, 2016 at 9:29 AM Xiaodi Wu  wrote:

> See, the key difference between for...in and .forEach() is that one allows
> for continue and break and the other doesn't. Swift is not a
> live-and-let-live language: if you truly believe that using continue leads
> to bad code, then propose its removal or the removal of for...in altogether.
>
> On Mon, Jun 13, 2016 at 11:21 let var go  wrote:
>
>> No, I wouldn't eliminate 'continue'. Even though I consider it a
>> sub-optimal solution, I would keep it in the language. Why? A couple of
>> reasons:
>>
>> 1) I don't like it, but even 'continue' may be the best available
>> solution in the context of a particular problem. I will look for other
>> options first, but I don't rule out the possibility that there might come a
>> time when it is the right tool for the job.
>>
>> 2) Some people like it. Not everyone feels the same way about it as me.
>> Some of the people who like it are better programmers than me. I have a lot
>> to learn, and someday I might discover that I love 'continue' after all.
>> Until then, live-and-let-live is what I say. Everyone should control their
>> own flow :) Keep your hands off my 'where' and I'll keep my hands off your
>> 'continue' :)
>>
>> On Mon, Jun 13, 2016 at 8:56 AM Xiaodi Wu  wrote:
>>
>>> On Mon, Jun 13, 2016 at 10:44 AM, let var go  wrote:
>>>
 I think we must be reading different discussions.

 What I have seen in this discussion is the following:

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

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

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

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

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

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

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

>>>
>>> This is quite the statement. It sounds like you'd be for the elimination
>>> of `continue`?
>>>
>>>

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

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

 Why? Because code like that is confusing. It becomes difficult to know
 how many times the loop will execute, what the looping logic is, etc. Sure,
 I might get away with it most of the time, 

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 11:50 AM, let var go  wrote:

> No, the key difference between for...in and forEach is that for...in
> allows for early exit. They both allow you to 'continue', though in forEach
> it is called 'return':
>
> // This prints odd numbers, skipping ("continuing") past the even numbers:
> (0..<100).forEach { if $0 % 2 == 0 { return } else { print($0) } }
>
> Early-exit ('break') is a different beast and requires a for...in loop.
>
> You missed my main point. In some situations even 'continue' may prove to
> be useful. It is not my preferred method.
>
> Why do you say, "Swift is not a live-and-let-live language?" Where do you
> get that from? Are you really saying that there is not room in the Swift
> community for people with different coding styles and preferences? I truly
> believe that that attitude will be very harmful to the long term future of
> the language.
>

In the words of Chris Lattner: We intentionally want Swift to have a common
“center of gravity” and be an “opinionated” language, rather than fall to
the “design by committee” approach that leads to a watered-down design.


>
> On Mon, Jun 13, 2016 at 9:29 AM Xiaodi Wu  wrote:
>
>> See, the key difference between for...in and .forEach() is that one
>> allows for continue and break and the other doesn't. Swift is not a
>> live-and-let-live language: if you truly believe that using continue leads
>> to bad code, then propose its removal or the removal of for...in altogether.
>>
>> On Mon, Jun 13, 2016 at 11:21 let var go  wrote:
>>
>>> No, I wouldn't eliminate 'continue'. Even though I consider it a
>>> sub-optimal solution, I would keep it in the language. Why? A couple of
>>> reasons:
>>>
>>> 1) I don't like it, but even 'continue' may be the best available
>>> solution in the context of a particular problem. I will look for other
>>> options first, but I don't rule out the possibility that there might come a
>>> time when it is the right tool for the job.
>>>
>>> 2) Some people like it. Not everyone feels the same way about it as me.
>>> Some of the people who like it are better programmers than me. I have a lot
>>> to learn, and someday I might discover that I love 'continue' after all.
>>> Until then, live-and-let-live is what I say. Everyone should control their
>>> own flow :) Keep your hands off my 'where' and I'll keep my hands off your
>>> 'continue' :)
>>>
>>> On Mon, Jun 13, 2016 at 8:56 AM Xiaodi Wu  wrote:
>>>
 On Mon, Jun 13, 2016 at 10:44 AM, let var go 
 wrote:

> I think we must be reading different discussions.
>
> What I have seen in this discussion is the following:
>
> a) The need to filter a for-in loop doesn't arise that often; but,
> b) When it does arise, everyone who has chimed in on this thread
> (except the two people who are proposing the change) thinks that the
> "where" clause is the clearest, most expressive way to do it.
>
> Something that would help me get on board with this change is more
> evidence about what kind of problems it is actually creating.
>
> As best I can tell, this proposal got started because "somewhere" some
> new programmers (no one knows how many) expressed some confusion (no one
> knows how seriously they were confused, or how long it took them to figure
> it out) about how the where clause worked in a for-in loop. For all we
> know, once they learned the way it works, they may have said, "Hey that's
> cool! I'm gonna use that from now on!"
>
> In other words, you seem to be talking about removing a feature that
> is liked by *a lot* people, based on some unsubstantiated reports of user
> error that may or may not have been totally unsubstantial.
>
> I don't want new programmers to be confused, either, but the "where"
> clause is such a basic programming construct - the keyword is new, but the
> idea itself is as old as programming - that I don't mind expecting new
> programmers to learn how to use it. The learning curve should be 
> incredibly
> short - it is nothing more than a filter operation.
>
> There's something else here that is really important to me, though I
> don't know how others feel about it.
>
> Using the guard...continue approach that you are promoting is a code
> smell. It puts control-flow logic inside the for-in loop. That is 
> something
> I have always tried to avoid. I know that the language allows for it, but 
> I
> believe it is bad programming practice. In fact, if you get rid of the
> `where` keyword, I'm still not going to use guard...continue. I'll just
> filter the collection first and then loop it.
>

 This is quite the statement. It sounds like you'd be for the
 elimination of `continue`?


>
> It is a code smell for the same reason 

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 11:41 AM, let var go  wrote:

>
>
> On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu  wrote:
>
>> Moreover, I should add, if your goal is to eliminate the possibility of
>> continuing and breaking from inside the loop, `.forEach()` does that
>> exactly, so your argument would be for the elimination of `for..in`
>> altogether.
>>
>
> I have no "goal" of eliminating the possibility of continuing or breaking
> from inside the loop. In general, it is not my goal to try and control how
> other people code their programs at all. I don't want to tell you that you
> can't 'continue' if you want to 'continue.'
>
> *I am not trying to make everyone adopt my own personal coding style
> and/or philosophy.*
>

We're not discussing style. You made a very strong claim: use of
`guard...continue` leads to 'smelly' code, or in other words bad code. In
other words, you claim that `guard...continue` is harmful. That is grounds
for removal, and if you believe it to be true, I encourage you to propose
it to the list and get feedback on that opinion.

If you're saying that you simply don't prefer it for reasons of 'style,'
again I emphasize that the topic at hand here is not about personal coding
style. The claim we are making is that `where` is harmful. I too like it
for style, and I'll be sad to see it go. But I have concluded that it must
go.


> There is also a big difference between 'break' and 'continue'. I am not
> afraid to use 'break', and I don't consider it a code smell. It allows for
> early exit from a loop based on conditions that are not always known at the
> time the loop is entered. for...in loops are necessary precisely because
> they allow for the early exit.
>
> You don't need for...in if you want to continue - you can use forEach for
> that. Instead of using 'continue', you just use 'return' without doing
> anything and it moves on to the next iteration. So really, the only purpose
> that for...in serves that is not served by forEach is early exit. But
> regardless, *even if for...in served no additional purpose that couldn't
> be served by forEach, I would keep it in the language because there are
> situations where I believe it is easier to read, and expressiveness and
> clarity are important to me.*
>
>
>>
>> On Mon, Jun 13, 2016 at 10:55 Xiaodi Wu  wrote:
>>
>>> On Mon, Jun 13, 2016 at 10:44 AM, let var go  wrote:
>>>
 I think we must be reading different discussions.

 What I have seen in this discussion is the following:

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

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

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

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

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

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

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

>>>
>>> This is quite the statement. It sounds like you'd be for the elimination
>>> of `continue`?
>>>
>>>

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

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

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

[let var go via swift-evolution]

On Mon, Jun 13, 2016 at 9:04 AM Xiaodi Wu  wrote:

> Moreover, I should add, if your goal is to eliminate the possibility of
> continuing and breaking from inside the loop, `.forEach()` does that
> exactly, so your argument would be for the elimination of `for..in`
> altogether.
>

I have no "goal" of eliminating the possibility of continuing or breaking
from inside the loop. In general, it is not my goal to try and control how
other people code their programs at all. I don't want to tell you that you
can't 'continue' if you want to 'continue.'

*I am not trying to make everyone adopt my own personal coding style and/or
philosophy.*

There is also a big difference between 'break' and 'continue'. I am not
afraid to use 'break', and I don't consider it a code smell. It allows for
early exit from a loop based on conditions that are not always known at the
time the loop is entered. for...in loops are necessary precisely because
they allow for the early exit.

You don't need for...in if you want to continue - you can use forEach for
that. Instead of using 'continue', you just use 'return' without doing
anything and it moves on to the next iteration. So really, the only purpose
that for...in serves that is not served by forEach is early exit. But
regardless, *even if for...in served no additional purpose that couldn't be
served by forEach, I would keep it in the language because there are
situations where I believe it is easier to read, and expressiveness and
clarity are important to me.*


>
> On Mon, Jun 13, 2016 at 10:55 Xiaodi Wu  wrote:
>
>> On Mon, Jun 13, 2016 at 10:44 AM, let var go  wrote:
>>
>>> I think we must be reading different discussions.
>>>
>>> What I have seen in this discussion is the following:
>>>
>>> a) The need to filter a for-in loop doesn't arise that often; but,
>>> b) When it does arise, everyone who has chimed in on this thread (except
>>> the two people who are proposing the change) thinks that the "where" clause
>>> is the clearest, most expressive way to do it.
>>>
>>> Something that would help me get on board with this change is more
>>> evidence about what kind of problems it is actually creating.
>>>
>>> As best I can tell, this proposal got started because "somewhere" some
>>> new programmers (no one knows how many) expressed some confusion (no one
>>> knows how seriously they were confused, or how long it took them to figure
>>> it out) about how the where clause worked in a for-in loop. For all we
>>> know, once they learned the way it works, they may have said, "Hey that's
>>> cool! I'm gonna use that from now on!"
>>>
>>> In other words, you seem to be talking about removing a feature that is
>>> liked by *a lot* people, based on some unsubstantiated reports of user
>>> error that may or may not have been totally unsubstantial.
>>>
>>> I don't want new programmers to be confused, either, but the "where"
>>> clause is such a basic programming construct - the keyword is new, but the
>>> idea itself is as old as programming - that I don't mind expecting new
>>> programmers to learn how to use it. The learning curve should be incredibly
>>> short - it is nothing more than a filter operation.
>>>
>>> There's something else here that is really important to me, though I
>>> don't know how others feel about it.
>>>
>>> Using the guard...continue approach that you are promoting is a code
>>> smell. It puts control-flow logic inside the for-in loop. That is something
>>> I have always tried to avoid. I know that the language allows for it, but I
>>> believe it is bad programming practice. In fact, if you get rid of the
>>> `where` keyword, I'm still not going to use guard...continue. I'll just
>>> filter the collection first and then loop it.
>>>
>>
>> This is quite the statement. It sounds like you'd be for the elimination
>> of `continue`?
>>
>>
>>>
>>> It is a code smell for the same reason that messing with the index
>>> inside a for;; loop was a code smell. I was always taught never to do this:
>>>
>>> for var i = 0; i < array.count, i++ {
>>>   if iWantThisToLoopAnExtraTime {
>>> i--
>>>   }
>>> }
>>>
>>> Why? Because code like that is confusing. It becomes difficult to know
>>> how many times the loop will execute, what the looping logic is, etc. Sure,
>>> I might get away with it most of the time, but it is bad practice and there
>>> is always a better way to do what you want to do. The only thing that keeps
>>> you from the better way is laziness.
>>>
>>> The same is true (albeit to a lesser degree) for the guard...continue.
>>> It may not be as extreme, but it is still a code smell. It divides the
>>> control-flow logic into two parts - one outside the loop, and one inside
>>> the loop, and it suddenly becomes twice as easy to miss something.
>>>
>>> Using for-in-where, all of the control-flow logic is on one single line,
>>> and once it is known that "where" operates as a filter operation, it all
>>> works 

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

[Xiaodi Wu via swift-evolution]

See, the key difference between for...in and .forEach() is that one allows
for continue and break and the other doesn't. Swift is not a
live-and-let-live language: if you truly believe that using continue leads
to bad code, then propose its removal or the removal of for...in altogether.

On Mon, Jun 13, 2016 at 11:21 let var go  wrote:

> No, I wouldn't eliminate 'continue'. Even though I consider it a
> sub-optimal solution, I would keep it in the language. Why? A couple of
> reasons:
>
> 1) I don't like it, but even 'continue' may be the best available solution
> in the context of a particular problem. I will look for other options
> first, but I don't rule out the possibility that there might come a time
> when it is the right tool for the job.
>
> 2) Some people like it. Not everyone feels the same way about it as me.
> Some of the people who like it are better programmers than me. I have a lot
> to learn, and someday I might discover that I love 'continue' after all.
> Until then, live-and-let-live is what I say. Everyone should control their
> own flow :) Keep your hands off my 'where' and I'll keep my hands off your
> 'continue' :)
>
> On Mon, Jun 13, 2016 at 8:56 AM Xiaodi Wu  wrote:
>
>> On Mon, Jun 13, 2016 at 10:44 AM, let var go  wrote:
>>
>>> I think we must be reading different discussions.
>>>
>>> What I have seen in this discussion is the following:
>>>
>>> a) The need to filter a for-in loop doesn't arise that often; but,
>>> b) When it does arise, everyone who has chimed in on this thread (except
>>> the two people who are proposing the change) thinks that the "where" clause
>>> is the clearest, most expressive way to do it.
>>>
>>> Something that would help me get on board with this change is more
>>> evidence about what kind of problems it is actually creating.
>>>
>>> As best I can tell, this proposal got started because "somewhere" some
>>> new programmers (no one knows how many) expressed some confusion (no one
>>> knows how seriously they were confused, or how long it took them to figure
>>> it out) about how the where clause worked in a for-in loop. For all we
>>> know, once they learned the way it works, they may have said, "Hey that's
>>> cool! I'm gonna use that from now on!"
>>>
>>> In other words, you seem to be talking about removing a feature that is
>>> liked by *a lot* people, based on some unsubstantiated reports of user
>>> error that may or may not have been totally unsubstantial.
>>>
>>> I don't want new programmers to be confused, either, but the "where"
>>> clause is such a basic programming construct - the keyword is new, but the
>>> idea itself is as old as programming - that I don't mind expecting new
>>> programmers to learn how to use it. The learning curve should be incredibly
>>> short - it is nothing more than a filter operation.
>>>
>>> There's something else here that is really important to me, though I
>>> don't know how others feel about it.
>>>
>>> Using the guard...continue approach that you are promoting is a code
>>> smell. It puts control-flow logic inside the for-in loop. That is something
>>> I have always tried to avoid. I know that the language allows for it, but I
>>> believe it is bad programming practice. In fact, if you get rid of the
>>> `where` keyword, I'm still not going to use guard...continue. I'll just
>>> filter the collection first and then loop it.
>>>
>>
>> This is quite the statement. It sounds like you'd be for the elimination
>> of `continue`?
>>
>>
>>>
>>> It is a code smell for the same reason that messing with the index
>>> inside a for;; loop was a code smell. I was always taught never to do this:
>>>
>>> for var i = 0; i < array.count, i++ {
>>>   if iWantThisToLoopAnExtraTime {
>>> i--
>>>   }
>>> }
>>>
>>> Why? Because code like that is confusing. It becomes difficult to know
>>> how many times the loop will execute, what the looping logic is, etc. Sure,
>>> I might get away with it most of the time, but it is bad practice and there
>>> is always a better way to do what you want to do. The only thing that keeps
>>> you from the better way is laziness.
>>>
>>> The same is true (albeit to a lesser degree) for the guard...continue.
>>> It may not be as extreme, but it is still a code smell. It divides the
>>> control-flow logic into two parts - one outside the loop, and one inside
>>> the loop, and it suddenly becomes twice as easy to miss something.
>>>
>>> Using for-in-where, all of the control-flow logic is on one single line,
>>> and once it is known that "where" operates as a filter operation, it all
>>> works together in a single, harmonious statement that declares exactly what
>>> is going to happen in a way that is totally unambiguous.
>>>
>>> So by getting rid of the "where" clause, I believe that you are actually
>>> encouraging bad programming practice. Instead of encouraging the new user
>>> to learn this very simple construct that will ultimately 

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

[let var go via swift-evolution]

No, I wouldn't eliminate 'continue'. Even though I consider it a
sub-optimal solution, I would keep it in the language. Why? A couple of
reasons:

1) I don't like it, but even 'continue' may be the best available solution
in the context of a particular problem. I will look for other options
first, but I don't rule out the possibility that there might come a time
when it is the right tool for the job.

2) Some people like it. Not everyone feels the same way about it as me.
Some of the people who like it are better programmers than me. I have a lot
to learn, and someday I might discover that I love 'continue' after all.
Until then, live-and-let-live is what I say. Everyone should control their
own flow :) Keep your hands off my 'where' and I'll keep my hands off your
'continue' :)

On Mon, Jun 13, 2016 at 8:56 AM Xiaodi Wu  wrote:

> On Mon, Jun 13, 2016 at 10:44 AM, let var go  wrote:
>
>> I think we must be reading different discussions.
>>
>> What I have seen in this discussion is the following:
>>
>> a) The need to filter a for-in loop doesn't arise that often; but,
>> b) When it does arise, everyone who has chimed in on this thread (except
>> the two people who are proposing the change) thinks that the "where" clause
>> is the clearest, most expressive way to do it.
>>
>> Something that would help me get on board with this change is more
>> evidence about what kind of problems it is actually creating.
>>
>> As best I can tell, this proposal got started because "somewhere" some
>> new programmers (no one knows how many) expressed some confusion (no one
>> knows how seriously they were confused, or how long it took them to figure
>> it out) about how the where clause worked in a for-in loop. For all we
>> know, once they learned the way it works, they may have said, "Hey that's
>> cool! I'm gonna use that from now on!"
>>
>> In other words, you seem to be talking about removing a feature that is
>> liked by *a lot* people, based on some unsubstantiated reports of user
>> error that may or may not have been totally unsubstantial.
>>
>> I don't want new programmers to be confused, either, but the "where"
>> clause is such a basic programming construct - the keyword is new, but the
>> idea itself is as old as programming - that I don't mind expecting new
>> programmers to learn how to use it. The learning curve should be incredibly
>> short - it is nothing more than a filter operation.
>>
>> There's something else here that is really important to me, though I
>> don't know how others feel about it.
>>
>> Using the guard...continue approach that you are promoting is a code
>> smell. It puts control-flow logic inside the for-in loop. That is something
>> I have always tried to avoid. I know that the language allows for it, but I
>> believe it is bad programming practice. In fact, if you get rid of the
>> `where` keyword, I'm still not going to use guard...continue. I'll just
>> filter the collection first and then loop it.
>>
>
> This is quite the statement. It sounds like you'd be for the elimination
> of `continue`?
>
>
>>
>> It is a code smell for the same reason that messing with the index inside
>> a for;; loop was a code smell. I was always taught never to do this:
>>
>> for var i = 0; i < array.count, i++ {
>>   if iWantThisToLoopAnExtraTime {
>> i--
>>   }
>> }
>>
>> Why? Because code like that is confusing. It becomes difficult to know
>> how many times the loop will execute, what the looping logic is, etc. Sure,
>> I might get away with it most of the time, but it is bad practice and there
>> is always a better way to do what you want to do. The only thing that keeps
>> you from the better way is laziness.
>>
>> The same is true (albeit to a lesser degree) for the guard...continue. It
>> may not be as extreme, but it is still a code smell. It divides the
>> control-flow logic into two parts - one outside the loop, and one inside
>> the loop, and it suddenly becomes twice as easy to miss something.
>>
>> Using for-in-where, all of the control-flow logic is on one single line,
>> and once it is known that "where" operates as a filter operation, it all
>> works together in a single, harmonious statement that declares exactly what
>> is going to happen in a way that is totally unambiguous.
>>
>> So by getting rid of the "where" clause, I believe that you are actually
>> encouraging bad programming practice. Instead of encouraging the new user
>> to learn this very simple construct that will ultimately make their code
>> safer and more expressive without dividing their control-flow logic
>> unnecessarily into two separate parts, you are encouraging them to just "do
>> what they know". I think that is terrible, and you are doing them a
>> disservice.
>>
>> And from a personal standpoint, you are telling me that I have to write
>> smelly code, even though there is this perfectly good non-smelly option
>> sitting right there, because you don't want someone else 

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

[Xiaodi Wu via swift-evolution]

Actually, at least where I'm from, it wouldn't be a comma, it'd be a bar: ∀
x ∈ X | x > 0.

Moreover, as has been pointed out, the use of 'where' in math is also not
universally loved.

On Mon, Jun 13, 2016 at 11:03 Charlie Monroe 
wrote:

> `while`, `until` and `unless` all implicate that the loop should break
> when the condition (or its negation) is met.
>
> On the other hand, `where` as it is seems logical to me. Anyone who
> considers serious coding is likely to have basic knowledge of mathematics,
> so something such as
>
> ∀x ∈ X, x > 0
>
> which translates into
>
> for x in X where x > 0
>
> in Swift, which is pretty much how you'd read the mathematical statement.
> Yes, there is a comma, not `where` in the formula but when reading, you say
> "where" (unless you say "every x greater than zero").
>
> > On Jun 13, 2016, at 5:26 PM, Erica Sadun  wrote:
> >
> >
> >> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> I am 100% with Charlie on this. Expressiveness has to do with the
> *effectiveness* of conveying a thought or a feeling.
> >>
> >> Keep "where". It is expressive. It conveys a specific idea effectively
> and concisely.
> >
> > For those of you in favor of retaining `where`, how do you feel about
> adding `while`, `until`, `unless`, etc?
> >
> > -- E
> >
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

Moreover, I should add, if your goal is to eliminate the possibility of
continuing and breaking from inside the loop, `.forEach()` does that
exactly, so your argument would be for the elimination of `for..in`
altogether.

On Mon, Jun 13, 2016 at 10:55 Xiaodi Wu  wrote:

> On Mon, Jun 13, 2016 at 10:44 AM, let var go  wrote:
>
>> I think we must be reading different discussions.
>>
>> What I have seen in this discussion is the following:
>>
>> a) The need to filter a for-in loop doesn't arise that often; but,
>> b) When it does arise, everyone who has chimed in on this thread (except
>> the two people who are proposing the change) thinks that the "where" clause
>> is the clearest, most expressive way to do it.
>>
>> Something that would help me get on board with this change is more
>> evidence about what kind of problems it is actually creating.
>>
>> As best I can tell, this proposal got started because "somewhere" some
>> new programmers (no one knows how many) expressed some confusion (no one
>> knows how seriously they were confused, or how long it took them to figure
>> it out) about how the where clause worked in a for-in loop. For all we
>> know, once they learned the way it works, they may have said, "Hey that's
>> cool! I'm gonna use that from now on!"
>>
>> In other words, you seem to be talking about removing a feature that is
>> liked by *a lot* people, based on some unsubstantiated reports of user
>> error that may or may not have been totally unsubstantial.
>>
>> I don't want new programmers to be confused, either, but the "where"
>> clause is such a basic programming construct - the keyword is new, but the
>> idea itself is as old as programming - that I don't mind expecting new
>> programmers to learn how to use it. The learning curve should be incredibly
>> short - it is nothing more than a filter operation.
>>
>> There's something else here that is really important to me, though I
>> don't know how others feel about it.
>>
>> Using the guard...continue approach that you are promoting is a code
>> smell. It puts control-flow logic inside the for-in loop. That is something
>> I have always tried to avoid. I know that the language allows for it, but I
>> believe it is bad programming practice. In fact, if you get rid of the
>> `where` keyword, I'm still not going to use guard...continue. I'll just
>> filter the collection first and then loop it.
>>
>
> This is quite the statement. It sounds like you'd be for the elimination
> of `continue`?
>
>
>>
>> It is a code smell for the same reason that messing with the index inside
>> a for;; loop was a code smell. I was always taught never to do this:
>>
>> for var i = 0; i < array.count, i++ {
>>   if iWantThisToLoopAnExtraTime {
>> i--
>>   }
>> }
>>
>> Why? Because code like that is confusing. It becomes difficult to know
>> how many times the loop will execute, what the looping logic is, etc. Sure,
>> I might get away with it most of the time, but it is bad practice and there
>> is always a better way to do what you want to do. The only thing that keeps
>> you from the better way is laziness.
>>
>> The same is true (albeit to a lesser degree) for the guard...continue. It
>> may not be as extreme, but it is still a code smell. It divides the
>> control-flow logic into two parts - one outside the loop, and one inside
>> the loop, and it suddenly becomes twice as easy to miss something.
>>
>> Using for-in-where, all of the control-flow logic is on one single line,
>> and once it is known that "where" operates as a filter operation, it all
>> works together in a single, harmonious statement that declares exactly what
>> is going to happen in a way that is totally unambiguous.
>>
>> So by getting rid of the "where" clause, I believe that you are actually
>> encouraging bad programming practice. Instead of encouraging the new user
>> to learn this very simple construct that will ultimately make their code
>> safer and more expressive without dividing their control-flow logic
>> unnecessarily into two separate parts, you are encouraging them to just "do
>> what they know". I think that is terrible, and you are doing them a
>> disservice.
>>
>> And from a personal standpoint, you are telling me that I have to write
>> smelly code, even though there is this perfectly good non-smelly option
>> sitting right there, because you don't want someone else to have to learn
>> something.
>>
>> On Mon, Jun 13, 2016 at 5:29 AM Xiaodi Wu  wrote:
>>
>>> I think this discussion has made it pretty plain that what is claimed to
>>> be 'so useful' is barely ever used. Moreover, it provides no independent
>>> uses. The point of these pitches is to sound out arguments, not, as far as
>>> I was aware, to take a vote.
>>>
>>> On Mon, Jun 13, 2016 at 1:54 AM Jose Cheyo Jimenez 
>>> wrote:
>>>
 --1

 I think it would be a waste of the community's time to do a formal
 review 

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

[Charlie Monroe via swift-evolution]

`while`, `until` and `unless` all implicate that the loop should break when the 
condition (or its negation) is met.

On the other hand, `where` as it is seems logical to me. Anyone who considers 
serious coding is likely to have basic knowledge of mathematics, so something 
such as

∀x ∈ X, x > 0

which translates into 

for x in X where x > 0

in Swift, which is pretty much how you'd read the mathematical statement. Yes, 
there is a comma, not `where` in the formula but when reading, you say "where" 
(unless you say "every x greater than zero").

> On Jun 13, 2016, at 5:26 PM, Erica Sadun  wrote:
> 
> 
>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution 
>>  wrote:
>> 
>> I am 100% with Charlie on this. Expressiveness has to do with the 
>> *effectiveness* of conveying a thought or a feeling.
>> 
>> Keep "where". It is expressive. It conveys a specific idea effectively and 
>> concisely.
> 
> For those of you in favor of retaining `where`, how do you feel about adding 
> `while`, `until`, `unless`, etc?
> 
> -- E
> 

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

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

[L. Mihalkovic via swift-evolution]

Regards
LM
(From mobile)

> On Jun 13, 2016, at 5:22 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> 
>> On Jun 13, 2016, at 10:16 AM, Xiaodi Wu  wrote:
>> 
>> On Mon, Jun 13, 2016 at 9:54 AM, Charlie Monroe  
>> wrote:
>> 
>>> On Jun 13, 2016, at 4:46 PM, Xiaodi Wu  wrote:
>>> 
>>> On Mon, Jun 13, 2016 at 9:28 AM, Sean Heber  wrote:
>>> I’m just (probably obtusely) suggesting that there are different levels and 
>>> styles of expression and that the existence of one does not render other 
>>> styles invalid.
>>> 
>>> In relation to the “where” debate, the fact that you can express everything 
>>> with “guard” or “if” as you can with “where” is not, in my mind, a strong  
>>> argument against “where” because it ignores other more intangible aspects 
>>> that are going to be a lot harder to quantify since they depend on the 
>>> context of the problem, the surrounding code, the mindset of the writer, 
>>> and the assumed mindset of the reader.
>>> 
>>> I don’t dispute that we *could* live without “where” - that is not the 
>>> point. We could also live without classes or generics or any of a variety 
>>> of other features - but why should we when we don’t have to?

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

>>> 
>>> I'm not sure where this comes in. I was clarifying what I mean when I call 
>>> a language construct 'expressive.' As I understand the term, `where` is not 
>>> expressive, whereas classes and generics are expressive.
>> 
>> Perhaps this is due to English not being my first language, but I go by the 
>> dictionary definition of expressive:
>> 
>> expressive (adjective) - effectively conveying thought or feeling.
>> 
>> And I believe that for-in-where is expressing the condition more effectively 
>> (and efficiently) than adding if/guard-continue into the actual code block.
>> 
>> That's fine for English, but I just mean that in a language design context 
>> I've always understood the word to encompass the *breadth* of thoughts that 
>> can be expressed. In that sense, `where` might express one thing 
>> economically, but it cannot express very many things at all, no matter how 
>> much text you write in a `where` clause.
> 
> Yes, true, there are certainly two meanings in play here - the technical 
> domain specific concept, and the more casual definition. I think the concern 
> of myself (and some others) is that the technical definition, perhaps 
> somewhat ironically, is not expressive enough to capture all of the facets of 
> expression that matter to all of us! I think this particular discussion is 
> taking place at the intersection of technology and liberal arts.
> 
> l8r
> Sean
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 10:54 AM, Erica Sadun  wrote:

>
> On Jun 13, 2016, at 9:44 AM, let var go via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think we must be reading different discussions.
>
> What I have seen in this discussion is the following:
>
> a) The need to filter a for-in loop doesn't arise that often; but,
> b) When it does arise, everyone who has chimed in on this thread (except
> the two people who are proposing the change) thinks that the "where" clause
> is the clearest, most expressive way to do it.
>
>
> As a point of order, may I request you stop singling out "the two people
> who are proposing the change" and discuss the merits of the pitch rather
> than the people involved in the discussion. Details of the Swift community
> code of conduct can be found here:
> https://swift.org/community/#code-of-conduct
>
> As syntactic sugar, the filtering syntax is rarely used, hard to discover,
> and elevates one style (continue if false) above others (continue if false,
> break if true, break if false
>

...and, a surprising number I noted from doing a rough GitHub search (many
more than I thought I would see): return if true, return if false,
fatalError if true, fatalError if false.


> ), which are not expressible using similar shorthand. It introduces a
> fluent style that discourages design comments at the point of use and can
> be difficult to breakpoint during debugging. The recommended alternative
> (using a separate guard) addresses all these points: better commenting,
> better breakpointing and debugging, and fully covers the domain of
> filtering and early exiting.
>
> In response, I'd like to hear why "continue if false" should be
> prioritized above the other options and should be retained, or
> alternatively why the suite should be completed (as in the original
> discussion with "while") in preference to the advantages accrued by guard.
>
> Thank you,
>
> -- Erica
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 10:44 AM, let var go  wrote:

> I think we must be reading different discussions.
>
> What I have seen in this discussion is the following:
>
> a) The need to filter a for-in loop doesn't arise that often; but,
> b) When it does arise, everyone who has chimed in on this thread (except
> the two people who are proposing the change) thinks that the "where" clause
> is the clearest, most expressive way to do it.
>
> Something that would help me get on board with this change is more
> evidence about what kind of problems it is actually creating.
>
> As best I can tell, this proposal got started because "somewhere" some new
> programmers (no one knows how many) expressed some confusion (no one knows
> how seriously they were confused, or how long it took them to figure it
> out) about how the where clause worked in a for-in loop. For all we know,
> once they learned the way it works, they may have said, "Hey that's cool!
> I'm gonna use that from now on!"
>
> In other words, you seem to be talking about removing a feature that is
> liked by *a lot* people, based on some unsubstantiated reports of user
> error that may or may not have been totally unsubstantial.
>
> I don't want new programmers to be confused, either, but the "where"
> clause is such a basic programming construct - the keyword is new, but the
> idea itself is as old as programming - that I don't mind expecting new
> programmers to learn how to use it. The learning curve should be incredibly
> short - it is nothing more than a filter operation.
>
> There's something else here that is really important to me, though I don't
> know how others feel about it.
>
> Using the guard...continue approach that you are promoting is a code
> smell. It puts control-flow logic inside the for-in loop. That is something
> I have always tried to avoid. I know that the language allows for it, but I
> believe it is bad programming practice. In fact, if you get rid of the
> `where` keyword, I'm still not going to use guard...continue. I'll just
> filter the collection first and then loop it.
>

This is quite the statement. It sounds like you'd be for the elimination of
`continue`?


>
> It is a code smell for the same reason that messing with the index inside
> a for;; loop was a code smell. I was always taught never to do this:
>
> for var i = 0; i < array.count, i++ {
>   if iWantThisToLoopAnExtraTime {
> i--
>   }
> }
>
> Why? Because code like that is confusing. It becomes difficult to know how
> many times the loop will execute, what the looping logic is, etc. Sure, I
> might get away with it most of the time, but it is bad practice and there
> is always a better way to do what you want to do. The only thing that keeps
> you from the better way is laziness.
>
> The same is true (albeit to a lesser degree) for the guard...continue. It
> may not be as extreme, but it is still a code smell. It divides the
> control-flow logic into two parts - one outside the loop, and one inside
> the loop, and it suddenly becomes twice as easy to miss something.
>
> Using for-in-where, all of the control-flow logic is on one single line,
> and once it is known that "where" operates as a filter operation, it all
> works together in a single, harmonious statement that declares exactly what
> is going to happen in a way that is totally unambiguous.
>
> So by getting rid of the "where" clause, I believe that you are actually
> encouraging bad programming practice. Instead of encouraging the new user
> to learn this very simple construct that will ultimately make their code
> safer and more expressive without dividing their control-flow logic
> unnecessarily into two separate parts, you are encouraging them to just "do
> what they know". I think that is terrible, and you are doing them a
> disservice.
>
> And from a personal standpoint, you are telling me that I have to write
> smelly code, even though there is this perfectly good non-smelly option
> sitting right there, because you don't want someone else to have to learn
> something.
>
> On Mon, Jun 13, 2016 at 5:29 AM Xiaodi Wu  wrote:
>
>> I think this discussion has made it pretty plain that what is claimed to
>> be 'so useful' is barely ever used. Moreover, it provides no independent
>> uses. The point of these pitches is to sound out arguments, not, as far as
>> I was aware, to take a vote.
>>
>> On Mon, Jun 13, 2016 at 1:54 AM Jose Cheyo Jimenez 
>> wrote:
>>
>>> --1
>>>
>>> I think it would be a waste of the community's time to do a formal
>>> review when only two people are in favor of this removal.
>>>
>>> 'for in where' is so useful especially since we don't have for;;; loops
>>> anymore. I'd say leave this alone; the majority doesn't want this changed.
>>>
>>>
>>>
>>> On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> I think this idea--if you don't like it, then you don't have 

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

[Erica Sadun via swift-evolution]

> On Jun 13, 2016, at 9:44 AM, let var go via swift-evolution 
>  wrote:
> 
> I think we must be reading different discussions.
> 
> What I have seen in this discussion is the following:
> 
> a) The need to filter a for-in loop doesn't arise that often; but,
> b) When it does arise, everyone who has chimed in on this thread (except the 
> two people who are proposing the change) thinks that the "where" clause is 
> the clearest, most expressive way to do it.

As a point of order, may I request you stop singling out "the two people who 
are proposing the change" and discuss the merits of the pitch rather than the 
people involved in the discussion. Details of the Swift community code of 
conduct can be found here: https://swift.org/community/#code-of-conduct 


As syntactic sugar, the filtering syntax is rarely used, hard to discover, and 
elevates one style (continue if false) above others (continue if false, break 
if true, break if false), which are not expressible using similar shorthand. It 
introduces a fluent style that discourages design comments at the point of use 
and can be difficult to breakpoint during debugging. The recommended 
alternative (using a separate guard) addresses all these points: better 
commenting, better breakpointing and debugging, and fully covers the domain of 
filtering and early exiting.

In response, I'd like to hear why "continue if false" should be prioritized 
above the other options and should be retained, or alternatively why the suite 
should be completed (as in the original discussion with "while") in preference 
to the advantages accrued by guard.

Thank you,

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

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

[let var go via swift-evolution]

I think we must be reading different discussions.

What I have seen in this discussion is the following:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On Mon, Jun 13, 2016 at 5:29 AM Xiaodi Wu  wrote:

> I think this discussion has made it pretty plain that what is claimed to
> be 'so useful' is barely ever used. Moreover, it provides no independent
> uses. The point of these pitches is to sound out arguments, not, as far as
> I was aware, to take a vote.
>
> On Mon, Jun 13, 2016 at 1:54 AM Jose Cheyo Jimenez 
> wrote:
>
>> --1
>>
>> I think it would be a waste of the community's time to do a formal review
>> when only two people are in favor of this removal.
>>
>> 'for in where' is so useful especially since we don't have for;;; loops
>> anymore. I'd say leave this alone; the majority doesn't want this changed.
>>
>>
>>
>> On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I think this idea--if you don't like it, then you don't have to use
>> it--is indicative of a key worry here: it's inessential to the language and
>> promotes dialects wherein certain people use it and others wherein they
>> don't. This is an anti-goal.
>>
>> On Fri, Jun 10, 2016 at 12:10 let var go  wrote:
>>
>> Leave it in!
>>>
>>> It's a great little tool. I don't 

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

[Sean Heber via swift-evolution]

> On Jun 13, 2016, at 10:26 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>> On Jun 13, 2016, at 9:23 AM, let var go via swift-evolution 
>>  wrote:
>> 
>> I am 100% with Charlie on this. Expressiveness has to do with the 
>> *effectiveness* of conveying a thought or a feeling.
>> 
>> Keep "where". It is expressive. It conveys a specific idea effectively and 
>> concisely.
> 
> For those of you in favor of retaining `where`, how do you feel about adding 
> `while`, `until`, `unless`, etc?
> 
> -- E

I think that “while” could be potentially useful, but since it hasn’t existed, 
I haven’t really considered what code might look like if that was possible. :P

l8r
Sean

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

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

[Erica Sadun via swift-evolution]

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

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

-- E

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

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

[let var go via swift-evolution]

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

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

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

> On Jun 13, 2016, at 4:46 PM, Xiaodi Wu  wrote:
>
> On Mon, Jun 13, 2016 at 9:28 AM, Sean Heber  wrote:
>
>> I’m just (probably obtusely) suggesting that there are different levels
>> and styles of expression and that the existence of one does not render
>> other styles invalid.
>>
>> In relation to the “where” debate, the fact that you can express
>> everything with “guard” or “if” as you can with “where” is not, in my mind,
>> a strong  argument against “where” because it ignores other more intangible
>> aspects that are going to be a lot harder to quantify since they depend on
>> the context of the problem, the surrounding code, the mindset of the
>> writer, and the assumed mindset of the reader.
>>
>> I don’t dispute that we *could* live without “where” - that is not the
>> point. We could also live without classes or generics or any of a variety
>> of other features - but why should we when we don’t have to?
>>
>
> I'm not sure where this comes in. I was clarifying what I mean when I call
> a language construct 'expressive.' As I understand the term, `where` is not
> expressive, whereas classes and generics are expressive.
>
>
> Perhaps this is due to English not being my first language, but I go by
> the dictionary definition of expressive:
>
> expressive (adjective) - effectively conveying thought or feeling.
>
> And I believe that for-in-where is expressing the condition more
> effectively (and efficiently) than adding if/guard-continue into the actual
> code block.
>
>
>
>>
>> l8r
>> Sean
>>
>>
>> > On Jun 13, 2016, at 9:19 AM, Xiaodi Wu  wrote:
>> >
>> > How do you mean? I don't follow.
>> > On Mon, Jun 13, 2016 at 09:11 Sean Heber  wrote:
>> > > On Jun 13, 2016, at 9:05 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > >
>> > > On Mon, Jun 13, 2016 at 8:58 AM, Charlie Monroe <
>> char...@charliemonroe.net> wrote:
>> > > if-continue. But I gladly took upon for-in-where as soon as I found
>> out about it since it's more expressive and simply is less typing.
>> > >
>> > > I don't think we use the term 'expressive' in the same way. I
>> understand it to mean that permitting the expression of more things. But of
>> course, `where` does only a subset of `guard...continue` or
>> `if...continue`; thus, less expressive.
>> >
>> > The fact that you could simply use the words “I am happy” to express
>> the concept of being happy does not mean that writing a complex poem that
>> also conveys happiness should therefore be prohibited.
>> >
>> > l8r
>> > Sean
>> >
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 9:54 AM, Charlie Monroe 
wrote:

>
> On Jun 13, 2016, at 4:46 PM, Xiaodi Wu  wrote:
>
> On Mon, Jun 13, 2016 at 9:28 AM, Sean Heber  wrote:
>
>> I’m just (probably obtusely) suggesting that there are different levels
>> and styles of expression and that the existence of one does not render
>> other styles invalid.
>>
>> In relation to the “where” debate, the fact that you can express
>> everything with “guard” or “if” as you can with “where” is not, in my mind,
>> a strong  argument against “where” because it ignores other more intangible
>> aspects that are going to be a lot harder to quantify since they depend on
>> the context of the problem, the surrounding code, the mindset of the
>> writer, and the assumed mindset of the reader.
>>
>> I don’t dispute that we *could* live without “where” - that is not the
>> point. We could also live without classes or generics or any of a variety
>> of other features - but why should we when we don’t have to?
>>
>
> I'm not sure where this comes in. I was clarifying what I mean when I call
> a language construct 'expressive.' As I understand the term, `where` is not
> expressive, whereas classes and generics are expressive.
>
>
> Perhaps this is due to English not being my first language, but I go by
> the dictionary definition of expressive:
>
> expressive (adjective) - effectively conveying thought or feeling.
>
> And I believe that for-in-where is expressing the condition more
> effectively (and efficiently) than adding if/guard-continue into the actual
> code block.
>

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

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

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

[Charlie Monroe via swift-evolution]

> On Jun 13, 2016, at 4:46 PM, Xiaodi Wu  wrote:
> 
> On Mon, Jun 13, 2016 at 9:28 AM, Sean Heber  > wrote:
> I’m just (probably obtusely) suggesting that there are different levels and 
> styles of expression and that the existence of one does not render other 
> styles invalid.
> 
> In relation to the “where” debate, the fact that you can express everything 
> with “guard” or “if” as you can with “where” is not, in my mind, a strong  
> argument against “where” because it ignores other more intangible aspects 
> that are going to be a lot harder to quantify since they depend on the 
> context of the problem, the surrounding code, the mindset of the writer, and 
> the assumed mindset of the reader.
> 
> I don’t dispute that we *could* live without “where” - that is not the point. 
> We could also live without classes or generics or any of a variety of other 
> features - but why should we when we don’t have to?
> 
> I'm not sure where this comes in. I was clarifying what I mean when I call a 
> language construct 'expressive.' As I understand the term, `where` is not 
> expressive, whereas classes and generics are expressive.

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

expressive (adjective) - effectively conveying thought or feeling.

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

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

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

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 9:28 AM, Sean Heber  wrote:

> I’m just (probably obtusely) suggesting that there are different levels
> and styles of expression and that the existence of one does not render
> other styles invalid.
>
> In relation to the “where” debate, the fact that you can express
> everything with “guard” or “if” as you can with “where” is not, in my mind,
> a strong  argument against “where” because it ignores other more intangible
> aspects that are going to be a lot harder to quantify since they depend on
> the context of the problem, the surrounding code, the mindset of the
> writer, and the assumed mindset of the reader.
>
> I don’t dispute that we *could* live without “where” - that is not the
> point. We could also live without classes or generics or any of a variety
> of other features - but why should we when we don’t have to?
>

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


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

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 9:27 AM, Vladimir.S  wrote:

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

Sequences, not just collections.

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


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


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


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

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


> Personally I don't insist on `where` keyword, probably we can find another
> word, so it will not be mixed with `where` in other places of the language.
>
> Why not `filter` instead of `where` ?
>
> for item in collection filter item < 10 {..}
>
> we have .filter for collections, it is clear what it means, `filter` in
> `for-in` mimics the same behavior, etc
>
> I'd even suggest to make `for-in` loop more powerful with adding suggested
> 'while' but as under another name. So, `for-in` will be a powerful
> construct to iterate, filter and break processing of collections - the only
> one purpose why we need `for-in` at all.
>

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


>
> for item in collection until item > 100 {..}
> or
> for item in collection break item > 100 {..}
> or
> for item in collection breakif item > 100 {..}
> or
> for item in collection limit item > 100 {..}
> or
> for item in collection stop item > 100 {..}
> or other keyword.
>
>
> On 13.06.2016 16:36, Xiaodi Wu via swift-evolution wrote:
>
>> On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope > > wrote:
>>
>> Are you really surprised that some people don't want this taken away?
>>
>>
>> Nope, that's to be expected.
>>
>>
>> The burden should be on those that want it taken out of the language
>> and not those that want it kept. After all something is being removed
>> and it should be a delicate process.
>>
>>
>> Agreed. We who think it's better to take this syntax out have advanced an
>> argument with several prongs. Namely, that the `where` clause serves no
>> independent purpose; that a more general solution has already been added
>> to
>> the language (as well as another in the stdlib); that the `where` clause
>> is
>> not necessary for progressive disclosure to new users before they're ready
>> for the general solution; that it is, at present, rarely used in practice;
>> that it has no analog in other commonly used general purpose languages in
>> the C family; that it is the remnant of a direction in which the core team
>> later decided not to pursue; and that, given its lack of utility, lack of
>> use, and vestigial state, being the cause of confusion even among a small
>> number of users (if their number be small) is grounds to conclude that it
>> is harmful to the language and therefore ought to be removed.
>>
>>
>> Don't be surprised when the defenders say it is more readable to them.
>> That is a *sound* argument in my opinion.
>>
>>
>> IMO, it cannot stand on its own as a complete argument for saving a
>> feature
>> in the face of the arguments we've advanced. Couldn't you say the same for
>> `++` or `for;;` loops? I'd say our case is at least as strong as that for
>> `for;;` loops. By comparison, if I recall, the `for;;` loop was argued to
>> be ill-fitting the rest of the language and lacking in usage, but it
>> certainly had utility independent of `for...in` loops and was well
>> precedented in C languages.
>>
>>
>>
>> Brandon
>>
>> Sent from my iPad
>>
>> On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution
>> > wrote:
>>
>> This is not a sound argument. If your filtering can be expressed as a
>>> where clause, then you would only have to read one line into the loop
>>> to see it in the form of a guard clause.
>>>
>>> Moreover, if what you're arguing is that you shouldn't ever have to
>>> 

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

[Sean Heber via swift-evolution]

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

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

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

l8r
Sean


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

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

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

[Vladimir.S via swift-evolution]

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


*Filtering* is another important operation we often need during the 
iteration of collection. This is why many of us want to keep `where` for 
`for-in` loop. Yes, as sugar, because it really simplifies our every day 
coding(processing of collections) and makes the code more readable(IMO) and 
understandable(IMO).


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


Why not `filter` instead of `where` ?

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

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


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


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


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

On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope > wrote:

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


Nope, that's to be expected.


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


Agreed. We who think it's better to take this syntax out have advanced an
argument with several prongs. Namely, that the `where` clause serves no
independent purpose; that a more general solution has already been added to
the language (as well as another in the stdlib); that the `where` clause is
not necessary for progressive disclosure to new users before they're ready
for the general solution; that it is, at present, rarely used in practice;
that it has no analog in other commonly used general purpose languages in
the C family; that it is the remnant of a direction in which the core team
later decided not to pursue; and that, given its lack of utility, lack of
use, and vestigial state, being the cause of confusion even among a small
number of users (if their number be small) is grounds to conclude that it
is harmful to the language and therefore ought to be removed.


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


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



Brandon

Sent from my iPad

On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution
> wrote:


This is not a sound argument. If your filtering can be expressed as a
where clause, then you would only have to read one line into the loop
to see it in the form of a guard clause.

Moreover, if what you're arguing is that you shouldn't ever have to
*read* inside the loop to know if a sequence is filtered, how do you
propose that we do that? Remove the continue keyword?

On Mon, Jun 13, 2016 at 6:16 AM Jean-Daniel Dupas via swift-evolution
> wrote:

-1 for the removal.

When I read code, I find it far more visible that a loop is over
a filter list when the filter clause is on the same line, than
when the filter clause is inside the loop.

Having to read the full content of the loop to determine if the
list is filtered or not is not an improvement IMHO.

Moreover, I find it far cleaner to use the where clause that
having to remember than I have to use the lazy accessor to avoid
a performance hit.


Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution
> a
écrit :


And to follow-up to myself once again, I went to my "Cool 3rd
Party Swift Repos" folder and did the same search. Among the 15
repos in that folder, a joint search returned about 650 hits on
for-in (again with some 

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

[Xiaodi Wu via swift-evolution]

How do you mean? I don't follow.
On Mon, Jun 13, 2016 at 09:11 Sean Heber  wrote:

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

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 8:49 AM, Brandon Knope  wrote:

>
>
> Sent from my iPad
>
> On Jun 13, 2016, at 9:36 AM, Xiaodi Wu  wrote:
>
> On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope  wrote:
>
>> Are you really surprised that some people don't want this taken away?
>>
>
> Nope, that's to be expected.
>
>
>> The burden should be on those that want it taken out of the language and
>> not those that want it kept. After all something is being removed and it
>> should be a delicate process.
>>
>
> Agreed. We who think it's better to take this syntax out have advanced an
> argument with several prongs. Namely, that the `where` clause serves no
> independent purpose;
>
>
> What does this mean or matter?
>

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


>
> that a more general solution has already been added to the language (as
> well as another in the stdlib);
>
>
> We have sugar all over the place to make features more palatable
>

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


>
> that the `where` clause is not necessary for progressive disclosure to new
> users before they're ready for the general solution;
>
>
> I have no clue what this is suppose to mean
>

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

> that it is, at present, rarely used in practice;
>
>
> It was added in the official release less than a year ago and it's not
> really documented well. And I'm not convinced it's rarely used in practice
> especially when it's exactly what you want
>
>
I've endeavored to outline why it's rarely exactly what you want. Whether
you buy it or not, well, that's another matter.


> that it has no analog in other commonly used general purpose languages in
> the C family;
>
>
> Why is this a good argument for its removal?
>

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

that it is the remnant of a direction in which the core team later decided
> not to pursue;
>
> I don't know anything about this but it sure seemed at one point they
> really liked where. It had to have gone through their own rigorous review
> process to be added in the first place?
>

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


>
> and that, given its lack of utility, lack of use, and vestigial state,
>
>
> Another opinion. This doesn't seem like a definitive argument for its
> removal
>

This is a summation of the prongs mentioned above.

being the cause of confusion even among a small number of users (if their
> number be small) is grounds to conclude that it is harmful to the language
> and therefore ought to be removed.
>
>
> "Harmful to the language" seems a bit extreme.
>
> I would love to hear more from the core team on this but I know they are
> just too busy right now
>
> Brandon
>
>
>
>
>> Don't be surprised when the defenders say it is more readable to them.
>> That is a *sound* argument in my opinion.
>>
>
> IMO, it cannot stand on its own as a complete argument for saving a
> feature in the face of the arguments we've advanced. Couldn't you say the
> same for `++` or `for;;` loops? I'd say our case is at least as strong as
> that for `for;;` loops. By comparison, if I recall, the `for;;` loop was
> argued to be ill-fitting the rest of the language and lacking in usage, but
> it certainly had utility independent of `for...in` loops and was well
> precedented in C languages.
>
>
>>
>> Brandon
>>
>> Sent from my iPad
>>
>> On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> This is not a sound argument. If your filtering can be expressed as a
>> where clause, then you would only have to read one line into the loop to
>> see it in the form of a guard clause.
>>
>> Moreover, if what you're arguing is that you shouldn't ever have to
>> *read* inside the loop to know if a sequence is filtered, how do you
>> propose that we do 

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

[Sean Heber via swift-evolution]

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

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

l8r
Sean

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

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 8:58 AM, Charlie Monroe 
wrote:

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

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


>
> On Jun 13, 2016, at 2:24 PM, Xiaodi Wu  wrote:
>
> What did you use before `where` existed?
>
> On Mon, Jun 13, 2016 at 1:29 AM Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift
>> Repos" folder and did the same search. Among the 15 repos in that folder, a
>> joint search returned about 650 hits on for-in (again with some false
>> positives) and not a single for-in-while use.
>>
>> -- E
>>
>>
>> Not to undermine this fact, but I believe the fact that `where` can be
>> used in a for loop is not widely known. I didn't know about it until about
>> a month ago (haven't really read much docs, but most people don't either).
>>
>> But after I found out about it, I started using it and it IMHO improved
>> readability of my code. Not by much, but it's the little things that make
>> you smile, right?
>>
>> Many people here argument that `where` is a Swift speciality and needs to
>> be learned by the developer - the alternative is to teach the person what's
>> the proper alternative - that using .filter can have performance impact and
>> that the *correct* way is to use guard within the for loop. And that's IMHO
>> much worse than teaching a person about using `where` within a for loop.
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

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

> On Jun 13, 2016, at 2:24 PM, Xiaodi Wu  wrote:
> 
> What did you use before `where` existed?
> 
> On Mon, Jun 13, 2016 at 1:29 AM Charlie Monroe via swift-evolution 
> > wrote:
>> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift 
>> Repos" folder and did the same search. Among the 15 repos in that folder, a 
>> joint search returned about 650 hits on for-in (again with some false 
>> positives) and not a single for-in-while use.
>> 
> 
>> -- E
> 
> Not to undermine this fact, but I believe the fact that `where` can be used 
> in a for loop is not widely known. I didn't know about it until about a month 
> ago (haven't really read much docs, but most people don't either).
> 
> But after I found out about it, I started using it and it IMHO improved 
> readability of my code. Not by much, but it's the little things that make you 
> smile, right?
> 
> Many people here argument that `where` is a Swift speciality and needs to be 
> learned by the developer - the alternative is to teach the person what's the 
> proper alternative - that using .filter can have performance impact and that 
> the *correct* way is to use guard within the for loop. And that's IMHO much 
> worse than teaching a person about using `where` within a for loop.
> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

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

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

[Brandon Knope via swift-evolution]

Sent from my iPad

> On Jun 13, 2016, at 9:36 AM, Xiaodi Wu  wrote:
> 
>> On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope  wrote:
>> Are you really surprised that some people don't want this taken away?
> 
> Nope, that's to be expected.
>  
>> The burden should be on those that want it taken out of the language and not 
>> those that want it kept. After all something is being removed and it should 
>> be a delicate process. 
> 
> Agreed. We who think it's better to take this syntax out have advanced an 
> argument with several prongs. Namely, that the `where` clause serves no 
> independent purpose;

What does this mean or matter?

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

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

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

I have no clue what this is suppose to mean


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

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


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

Why is this a good argument for its removal?


> that it is the remnant of a direction in which the core team later decided 
> not to pursue;
I don't know anything about this but it sure seemed at one point they really 
liked where. It had to have gone through their own rigorous review process to 
be added in the first place?

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

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

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

"Harmful to the language" seems a bit extreme. 

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

Brandon 


>  
>> Don't be surprised when the defenders say it is more readable to them. That 
>> is a *sound* argument in my opinion. 
> 
> IMO, it cannot stand on its own as a complete argument for saving a feature 
> in the face of the arguments we've advanced. Couldn't you say the same for 
> `++` or `for;;` loops? I'd say our case is at least as strong as that for 
> `for;;` loops. By comparison, if I recall, the `for;;` loop was argued to be 
> ill-fitting the rest of the language and lacking in usage, but it certainly 
> had utility independent of `for...in` loops and was well precedented in C 
> languages.
>  
>> 
>> Brandon
>> 
>> Sent from my iPad
>> 
>>> On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> This is not a sound argument. If your filtering can be expressed as a where 
>>> clause, then you would only have to read one line into the loop to see it 
>>> in the form of a guard clause.
>>> 
>>> Moreover, if what you're arguing is that you shouldn't ever have to *read* 
>>> inside the loop to know if a sequence is filtered, how do you propose that 
>>> we do that? Remove the continue keyword?
>>> 
 On Mon, Jun 13, 2016 at 6:16 AM Jean-Daniel Dupas via swift-evolution 
  wrote:
 -1 for the removal.
 
 When I read code, I find it far more visible that a loop is over a filter 
 list when the filter clause is on the same line, than when the filter 
 clause is inside the loop.
 
 Having to read the full content of the loop to determine if the list is 
 filtered or not is not an improvement IMHO.
 
 Moreover, I find it far cleaner to use the where clause that having to 
 remember than I have to use the lazy accessor to avoid a performance hit.
 
>> Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution 
>>  a écrit :
>> 
>> And to follow-up to myself once again, I went to my "Cool 3rd Party 
>> Swift Repos" folder and did the same search. Among the 15 repos in that 
>> folder, a joint search returned about 650 hits on for-in (again with 
>> some false positives) and not a single for-in-while use.
>> 
>> -- E
> 
> Not to undermine this fact, but I believe the fact that `where` can be 
> used in a for loop is not widely known. I didn't know about it until 
> about a month ago (haven't really read much docs, but most people don't 
> either).
> 
> But after I found out about it, I started using it and it IMHO improved 
> readability of my code. Not by much, but it's the little things that make 
> you smile, right?
> 
> Many people here argument that `where` is a Swift speciality and needs to 
> 

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

[Xiaodi Wu via swift-evolution]

On Mon, Jun 13, 2016 at 8:16 AM, Brandon Knope  wrote:

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

Nope, that's to be expected.


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

Agreed. We who think it's better to take this syntax out have advanced an
argument with several prongs. Namely, that the `where` clause serves no
independent purpose; that a more general solution has already been added to
the language (as well as another in the stdlib); that the `where` clause is
not necessary for progressive disclosure to new users before they're ready
for the general solution; that it is, at present, rarely used in practice;
that it has no analog in other commonly used general purpose languages in
the C family; that it is the remnant of a direction in which the core team
later decided not to pursue; and that, given its lack of utility, lack of
use, and vestigial state, being the cause of confusion even among a small
number of users (if their number be small) is grounds to conclude that it
is harmful to the language and therefore ought to be removed.


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

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


>
> Brandon
>
> Sent from my iPad
>
> On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> This is not a sound argument. If your filtering can be expressed as a
> where clause, then you would only have to read one line into the loop to
> see it in the form of a guard clause.
>
> Moreover, if what you're arguing is that you shouldn't ever have to *read*
> inside the loop to know if a sequence is filtered, how do you propose that
> we do that? Remove the continue keyword?
>
> On Mon, Jun 13, 2016 at 6:16 AM Jean-Daniel Dupas via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> -1 for the removal.
>>
>> When I read code, I find it far more visible that a loop is over a filter
>> list when the filter clause is on the same line, than when the filter
>> clause is inside the loop.
>>
>> Having to read the full content of the loop to determine if the list is
>> filtered or not is not an improvement IMHO.
>>
>> Moreover, I find it far cleaner to use the where clause that having to
>> remember than I have to use the lazy accessor to avoid a performance hit.
>>
>> Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>>
>> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift
>> Repos" folder and did the same search. Among the 15 repos in that folder, a
>> joint search returned about 650 hits on for-in (again with some false
>> positives) and not a single for-in-while use.
>>
>> -- E
>>
>>
>> Not to undermine this fact, but I believe the fact that `where` can be
>> used in a for loop is not widely known. I didn't know about it until about
>> a month ago (haven't really read much docs, but most people don't either).
>>
>> But after I found out about it, I started using it and it IMHO improved
>> readability of my code. Not by much, but it's the little things that make
>> you smile, right?
>>
>> Many people here argument that `where` is a Swift speciality and needs to
>> be learned by the developer - the alternative is to teach the person what's
>> the proper alternative - that using .filter can have performance impact and
>> that the *correct* way is to use guard within the for loop. And that's IMHO
>> much worse than teaching a person about using `where` within a for loop.
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org

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

[Brandon Knope via swift-evolution]

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

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

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

Brandon

Sent from my iPad

> On Jun 13, 2016, at 8:33 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> This is not a sound argument. If your filtering can be expressed as a where 
> clause, then you would only have to read one line into the loop to see it in 
> the form of a guard clause.
> 
> Moreover, if what you're arguing is that you shouldn't ever have to *read* 
> inside the loop to know if a sequence is filtered, how do you propose that we 
> do that? Remove the continue keyword?
> 
>> On Mon, Jun 13, 2016 at 6:16 AM Jean-Daniel Dupas via swift-evolution 
>>  wrote:
>> -1 for the removal.
>> 
>> When I read code, I find it far more visible that a loop is over a filter 
>> list when the filter clause is on the same line, than when the filter clause 
>> is inside the loop.
>> 
>> Having to read the full content of the loop to determine if the list is 
>> filtered or not is not an improvement IMHO.
>> 
>> Moreover, I find it far cleaner to use the where clause that having to 
>> remember than I have to use the lazy accessor to avoid a performance hit.
>> 
 Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution 
  a écrit :
 
 And to follow-up to myself once again, I went to my "Cool 3rd Party Swift 
 Repos" folder and did the same search. Among the 15 repos in that folder, 
 a joint search returned about 650 hits on for-in (again with some false 
 positives) and not a single for-in-while use.
 
 -- E
>>> 
>>> Not to undermine this fact, but I believe the fact that `where` can be used 
>>> in a for loop is not widely known. I didn't know about it until about a 
>>> month ago (haven't really read much docs, but most people don't either).
>>> 
>>> But after I found out about it, I started using it and it IMHO improved 
>>> readability of my code. Not by much, but it's the little things that make 
>>> you smile, right?
>>> 
>>> Many people here argument that `where` is a Swift speciality and needs to 
>>> be learned by the developer - the alternative is to teach the person what's 
>>> the proper alternative - that using .filter can have performance impact and 
>>> that the *correct* way is to use guard within the for loop. And that's IMHO 
>>> much worse than teaching a person about using `where` within a for loop.
>>> 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

This is not a sound argument. If your filtering can be expressed as a where
clause, then you would only have to read one line into the loop to see it
in the form of a guard clause.

Moreover, if what you're arguing is that you shouldn't ever have to *read*
inside the loop to know if a sequence is filtered, how do you propose that
we do that? Remove the continue keyword?

On Mon, Jun 13, 2016 at 6:16 AM Jean-Daniel Dupas via swift-evolution <
swift-evolution@swift.org> wrote:

> -1 for the removal.
>
> When I read code, I find it far more visible that a loop is over a filter
> list when the filter clause is on the same line, than when the filter
> clause is inside the loop.
>
> Having to read the full content of the loop to determine if the list is
> filtered or not is not an improvement IMHO.
>
> Moreover, I find it far cleaner to use the where clause that having to
> remember than I have to use the lazy accessor to avoid a performance hit.
>
> Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift
> Repos" folder and did the same search. Among the 15 repos in that folder, a
> joint search returned about 650 hits on for-in (again with some false
> positives) and not a single for-in-while use.
>
> -- E
>
>
> Not to undermine this fact, but I believe the fact that `where` can be
> used in a for loop is not widely known. I didn't know about it until about
> a month ago (haven't really read much docs, but most people don't either).
>
> But after I found out about it, I started using it and it IMHO improved
> readability of my code. Not by much, but it's the little things that make
> you smile, right?
>
> Many people here argument that `where` is a Swift speciality and needs to
> be learned by the developer - the alternative is to teach the person what's
> the proper alternative - that using .filter can have performance impact and
> that the *correct* way is to use guard within the for loop. And that's IMHO
> much worse than teaching a person about using `where` within a for loop.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[L. Mihalkovic via swift-evolution]

> On Jun 13, 2016, at 1:23 PM, Charlie Monroe via swift-evolution 
>  wrote:
> 
>> Moreover, I find it far cleaner to use the where clause that having to 
>> remember than I have to use the lazy accessor to avoid a performance hit.
> 
> See the benchmarks me and Erica have posted here a few days back - even with 
> the lazy accessor, if you decided to use filter(_:), you lost 10+% of 
> performance. Correct way to do this without `where` and without performance 
> penalization is to use guard within the for-in loop.

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


> 
>> 
 Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution 
  a écrit :
 
 And to follow-up to myself once again, I went to my "Cool 3rd Party Swift 
 Repos" folder and did the same search. Among the 15 repos in that folder, 
 a joint search returned about 650 hits on for-in (again with some false 
 positives) and not a single for-in-while use.
 
 -- E
>>> 
>>> Not to undermine this fact, but I believe the fact that `where` can be used 
>>> in a for loop is not widely known. I didn't know about it until about a 
>>> month ago (haven't really read much docs, but most people don't either).
>>> 
>>> But after I found out about it, I started using it and it IMHO improved 
>>> readability of my code. Not by much, but it's the little things that make 
>>> you smile, right?
>>> 
>>> Many people here argument that `where` is a Swift speciality and needs to 
>>> be learned by the developer - the alternative is to teach the person what's 
>>> the proper alternative - that using .filter can have performance impact and 
>>> that the *correct* way is to use guard within the for loop. And that's IMHO 
>>> much worse than teaching a person about using `where` within a for loop.
>>> 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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

On Mon, Jun 13, 2016 at 1:54 AM Jose Cheyo Jimenez 
wrote:

> --1
>
> I think it would be a waste of the community's time to do a formal review
> when only two people are in favor of this removal.
>
> 'for in where' is so useful especially since we don't have for;;; loops
> anymore. I'd say leave this alone; the majority doesn't want this changed.
>
>
>
> On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think this idea--if you don't like it, then you don't have to use it--is
> indicative of a key worry here: it's inessential to the language and
> promotes dialects wherein certain people use it and others wherein they
> don't. This is an anti-goal.
>
> On Fri, Jun 10, 2016 at 12:10 let var go  wrote:
>
> Leave it in!
>>
>> It's a great little tool. I don't use it very often, but when I do it is
>> because I've decided that in the context of that piece of code it does
>> exactly what I want it to do with the maximum amount of clarity.
>>
>> If you don't like it, then don't use it, but I can't see how it detracts
>> from the language at all.
>>
>> The *only* argument that I have heard for removing it is that some people
>> don't immediately intuit how to use it. I didn't have any trouble with it
>> at all. It follows one of the most basic programming patterns ever: "For
>> all x in X, if predicate P is true, do something." The use of the keyword
>> "where" makes perfect sense in that context, and when I read it out loud,
>> it sounds natural: "For all x in X where P, do something." That is an
>> elegant, succinct, and clear way of stating exactly what I want my program
>> to do.
>>
>> I don't doubt that it has caused some confusion for some people, but I'm
>> not sold that that is a good enough reason to get rid of it. It seems
>> strange to get rid of a tool because not everyone understands how to use it
>> immediately, without ever having to ask a single question. As long as its
>> not a dangerous tool (and it isn't), then keep it in the workshop for those
>> times when it comes in handy. And even if there is some initial confusion,
>> it doesn't sound like it lasted that long. It's more like, "Does this work
>> like X, or does this work like Y? Let's see...oh, it works like X. Ok."
>> That's the entire learning curve...about 5 seconds of curiosity followed by
>> the blissful feeling of resolution.
>>
>> On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
> On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>> > And to follow-up to myself once again, I went to my "Cool 3rd Party
 Swift Repos" folder and did the same search. Among the 15 repos in that
 folder, a joint search returned about 650 hits on for-in (again with some
 false positives) and not a single for-in-while use.

 Weird. My own Swift projects (not on Github :P) use “where” all the
 time with for loops. I really like it and think it reads *and* writes far
 better as well as makes for nicer one-liners. In one project, by rough
 count, I have about 20 that use “where” vs. 40 in that same project not
 using “where”.

 In another smaller test project, there are only 10 for loops, but even
 so one still managed to use where.

 Not a lot of data without looking at even more projects, I admit, but
 this seems to suggest that the usage of “where” is going to be very
 developer-dependent. Perhaps there’s some factor of prior background at
 work here? (I’ve done a lot of SQL in another life, for example.)

>>> That is worrying if true, because it suggests that it's enabling
>>> 'dialects' of Swift, an explicit anti-goal of the language.
>>>
>>
 I feel like “where” is a more declarative construct and that we should
 be encouraging that way of thinking in general. When using it, it feels
 like “magic” for some reason - even though there’s nothing special about
 it. It feels like I’ve made the language work *for me* a little bit rather
 than me having to contort my solution to the will of the language. This may
 be highly subjective.

 l8r
 Sean

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

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

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

[Xiaodi Wu via swift-evolution]

What did you use before `where` existed?

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

> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift
> Repos" folder and did the same search. Among the 15 repos in that folder, a
> joint search returned about 650 hits on for-in (again with some false
> positives) and not a single for-in-while use.
>
> -- E
>
>
> Not to undermine this fact, but I believe the fact that `where` can be
> used in a for loop is not widely known. I didn't know about it until about
> a month ago (haven't really read much docs, but most people don't either).
>
> But after I found out about it, I started using it and it IMHO improved
> readability of my code. Not by much, but it's the little things that make
> you smile, right?
>
> Many people here argument that `where` is a Swift speciality and needs to
> be learned by the developer - the alternative is to teach the person what's
> the proper alternative - that using .filter can have performance impact and
> that the *correct* way is to use guard within the for loop. And that's IMHO
> much worse than teaching a person about using `where` within a for loop.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> Moreover, I find it far cleaner to use the where clause that having to 
> remember than I have to use the lazy accessor to avoid a performance hit.

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

> 
>> Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution 
>> > a écrit :
>> 
>>> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift 
>>> Repos" folder and did the same search. Among the 15 repos in that folder, a 
>>> joint search returned about 650 hits on for-in (again with some false 
>>> positives) and not a single for-in-while use.
>>> 
>>> -- E
>> 
>> Not to undermine this fact, but I believe the fact that `where` can be used 
>> in a for loop is not widely known. I didn't know about it until about a 
>> month ago (haven't really read much docs, but most people don't either).
>> 
>> But after I found out about it, I started using it and it IMHO improved 
>> readability of my code. Not by much, but it's the little things that make 
>> you smile, right?
>> 
>> Many people here argument that `where` is a Swift speciality and needs to be 
>> learned by the developer - the alternative is to teach the person what's the 
>> proper alternative - that using .filter can have performance impact and that 
>> the *correct* way is to use guard within the for loop. And that's IMHO much 
>> worse than teaching a person about using `where` within a for loop.
>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Jean-Daniel Dupas via swift-evolution]

-1 for the removal.

When I read code, I find it far more visible that a loop is over a filter list 
when the filter clause is on the same line, than when the filter clause is 
inside the loop.

Having to read the full content of the loop to determine if the list is 
filtered or not is not an improvement IMHO.

Moreover, I find it far cleaner to use the where clause that having to remember 
than I have to use the lazy accessor to avoid a performance hit.

> Le 13 juin 2016 à 06:39, Charlie Monroe via swift-evolution 
>  a écrit :
> 
>> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift 
>> Repos" folder and did the same search. Among the 15 repos in that folder, a 
>> joint search returned about 650 hits on for-in (again with some false 
>> positives) and not a single for-in-while use.
>> 
>> -- E
> 
> Not to undermine this fact, but I believe the fact that `where` can be used 
> in a for loop is not widely known. I didn't know about it until about a month 
> ago (haven't really read much docs, but most people don't either).
> 
> But after I found out about it, I started using it and it IMHO improved 
> readability of my code. Not by much, but it's the little things that make you 
> smile, right?
> 
> Many people here argument that `where` is a Swift speciality and needs to be 
> learned by the developer - the alternative is to teach the person what's the 
> proper alternative - that using .filter can have performance impact and that 
> the *correct* way is to use guard within the for loop. And that's IMHO much 
> worse than teaching a person about using `where` within a for loop.
> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Jose Cheyo Jimenez via swift-evolution]

--1

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

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



> On Jun 10, 2016, at 10:17 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I think this idea--if you don't like it, then you don't have to use it--is 
> indicative of a key worry here: it's inessential to the language and promotes 
> dialects wherein certain people use it and others wherein they don't. This is 
> an anti-goal.
> 
>> On Fri, Jun 10, 2016 at 12:10 let var go  wrote:
>> Leave it in!
>> 
>> It's a great little tool. I don't use it very often, but when I do it is 
>> because I've decided that in the context of that piece of code it does 
>> exactly what I want it to do with the maximum amount of clarity.
>> 
>> If you don't like it, then don't use it, but I can't see how it detracts 
>> from the language at all.
>> 
>> The *only* argument that I have heard for removing it is that some people 
>> don't immediately intuit how to use it. I didn't have any trouble with it at 
>> all. It follows one of the most basic programming patterns ever: "For all x 
>> in X, if predicate P is true, do something." The use of the keyword "where" 
>> makes perfect sense in that context, and when I read it out loud, it sounds 
>> natural: "For all x in X where P, do something." That is an elegant, 
>> succinct, and clear way of stating exactly what I want my program to do.
>> 
>> I don't doubt that it has caused some confusion for some people, but I'm not 
>> sold that that is a good enough reason to get rid of it. It seems strange to 
>> get rid of a tool because not everyone understands how to use it 
>> immediately, without ever having to ask a single question. As long as its 
>> not a dangerous tool (and it isn't), then keep it in the workshop for those 
>> times when it comes in handy. And even if there is some initial confusion, 
>> it doesn't sound like it lasted that long. It's more like, "Does this work 
>> like X, or does this work like Y? Let's see...oh, it works like X. Ok." 
>> That's the entire learning curve...about 5 seconds of curiosity followed by 
>> the blissful feeling of resolution.
>> 
>>> On Fri, Jun 10, 2016 at 9:32 AM Xiaodi Wu via swift-evolution 
>>>  wrote:
 On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution 
  wrote:
 > And to follow-up to myself once again, I went to my "Cool 3rd Party 
 > Swift Repos" folder and did the same search. Among the 15 repos in that 
 > folder, a joint search returned about 650 hits on for-in (again with 
 > some false positives) and not a single for-in-while use.
 
 Weird. My own Swift projects (not on Github :P) use “where” all the time 
 with for loops. I really like it and think it reads *and* writes far 
 better as well as makes for nicer one-liners. In one project, by rough 
 count, I have about 20 that use “where” vs. 40 in that same project not 
 using “where”.
 
 In another smaller test project, there are only 10 for loops, but even so 
 one still managed to use where.
 
 Not a lot of data without looking at even more projects, I admit, but this 
 seems to suggest that the usage of “where” is going to be very 
 developer-dependent. Perhaps there’s some factor of prior background at 
 work here? (I’ve done a lot of SQL in another life, for example.)
>>> 
>>> That is worrying if true, because it suggests that it's enabling 'dialects' 
>>> of Swift, an explicit anti-goal of the language.
>>>  
 
 I feel like “where” is a more declarative construct and that we should be 
 encouraging that way of thinking in general. When using it, it feels like 
 “magic” for some reason - even though there’s nothing special about it. It 
 feels like I’ve made the language work *for me* a little bit rather than 
 me having to contort my solution to the will of the language. This may be 
 highly subjective.
 
 l8r
 Sean
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> And to follow-up to myself once again, I went to my "Cool 3rd Party Swift 
> Repos" folder and did the same search. Among the 15 repos in that folder, a 
> joint search returned about 650 hits on for-in (again with some false 
> positives) and not a single for-in-while use.
> 
> -- E

Not to undermine this fact, but I believe the fact that `where` can be used in 
a for loop is not widely known. I didn't know about it until about a month ago 
(haven't really read much docs, but most people don't either).

But after I found out about it, I started using it and it IMHO improved 
readability of my code. Not by much, but it's the little things that make you 
smile, right?

Many people here argument that `where` is a Swift speciality and needs to be 
learned by the developer - the alternative is to teach the person what's the 
proper alternative - that using .filter can have performance impact and that 
the *correct* way is to use guard within the for loop. And that's IMHO much 
worse than teaching a person about using `where` within a for loop.

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

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

[plx via swift-evolution]

> 
> First, notice how your comment is related to the `where` clause but is 
> actually sitting on top of the loop itself. Second, one of these two tests 
> visits every element while the other doesn't, and it took me three reads 
> before I could see that because I literally couldn't find the `where` clause 
> the first two times I scanned through your code. This is a false 
> "parallelism," causing the very thing that *isn't* parallel to disappear from 
> the reader's eye. Compare instead this alternative, which also flips the 
> boolean assertion:
> 
> ```
> func testNaiveAncestor() {
>   for position in testPositions {
> // the root has no ancestor
> if position.isRootPosition { continue }
> // (notice how I don't even have to comment that we're skipping root,
> // because the code says it explicitly for me)
> 
> XCTAssertLessThan(position.naiveAncestor(), position)
>   }
> }
> ```

Fair enough; I added the comment when posting here…the original didn’t have 
one, because the where clause also explicitly says we’re skipping that one. 

To me the parallelism I care about is the following paraphrase:

  for testItem in allRelevantPossibilities { someBasicPropertyHolds(testItem) }
  for testItem in allRelevantPossibilities { someOtherPropertyHolds(testItem) }

…and adding the logic to skip the irrelevant option into the definition of 
“allRelevantPossibilities” seems to do a better job preserving the structural 
similarity I care about than throwing in some ad-hoc looking imperative logic 
into the test logic itself (even though functionally both are equivalent).

> 
> Now, with my rewriting, the part of your test that is strictly similar to the 
> other test looks parallel, and the one part that isn't at all similar (the 
> skipping part) stands out explicitly and is now self-documenting code.
> 
> 
> So `where` here, IMHO, isn’t *clearly* clearer in `testNaiveAncestor()`, but 
> it lets `testNaiveAncestor()` and `testNaiveSuccessor()` (etc.) be 
> *systemically*-clearer, as it were.
> 
> Second Pattern: relatedly, I find code is much clearer when `guard` is 
> only-ever used for early exits and early returns. 
> 
> There’s no requirement to *not* use `guard` and `continue` together, but if 
> one is willing to stick to `guard` == “early exit / early return” it makes 
> code much easier to read and audit.
> 
> In a handful of places I have for loops that would need both `continue`-style 
> conditionals and also early-exit conditionals; having `where` means I can 
> stick to using `guard` for early-exits, whereas without it I’d have extra 
> nesting or mixed “early-exit” guard and “continue” guard. 
> 
> I don't know what to say here. The fact is that `guard` with `continue` is a 
> documented and advertised feature of Swift; it's not simply supported by 
> accident. Of course, you're free to choose not to use that feature at all. 
> And it is true that, currently, `where` allows you to avoid that feature at 
> the top of a `for` loop, but anywhere else inside the loop and you'll have to 
> deal with extra nesting if you choose to reject `guard` with `continue`.

The same is true of `where`, no? It’s a part of the language, documented, free 
to use or not to use when or if you find it helpful (or not).

In the same way you seem to have with `where` after a for-in — and would prefer 
to not have to check for it, etc. — I have a hard time following mixed 
break/continue/return usage, and prefer to not have to check the body of each 
guard clause’s `else` to figure out the control flow.

I can understand that you find that difficulty baffling; I find your 
difficulties `where` baffling, but can accept they are sincere.

> IIUC, one of the motivating reasons for introducing `guard` was to solve the 
> pyramid of doom problem. So you're rejecting the intended solution for extra 
> nesting, at least in certain circumstances, a choice you're obviously free to 
> make in your own code. But when it comes to designing a language for 
> everyone, the fact that some users reject the intended solution would be 
> grounds for re-examining that solution (i.e. `guard`), but the mantra here 
> has always been one solution where possible and not multiple. So this 
> certainly cannot be a justification for another feature (i.e. `where`) which 
> only incidentally provides a substitute solution in certain situations.

Personally I found this use of `where` completely unremarkable and something I 
never thought about until I saw this discussion gaining momentum; I was already 
used to similar constructs so it just seemed useful in a familiar and 
thoroughly-uninteresting way.

That said, I could get behind excising it if there was serious interest in 
eventually building-in something like LINQ or comprehensions (etc.); `where` 
after a for-in is at this point a bit of an odd duckling.

___
swift-evolution mailing list
swift-evolution@swift.org

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

[Xiaodi Wu via swift-evolution]

On Sun, Jun 12, 2016 at 9:23 AM, L. Mihalkovic  wrote:

>
> On Jun 12, 2016, at 3:21 PM, Thorsten Seitz  wrote:
>
>
> Am 12.06.2016 um 12:02 schrieb L Mihalkovic  >:
>
>
> On Jun 11, 2016, at 11:45 PM, Xiaodi Wu  wrote:
>
>
>
> On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz 
> wrote:
>
>>
>>
>> Am 11.06.2016 um 22:29 schrieb L. Mihalkovic <
>> laurent.mihalko...@gmail.com>:
>>
>>
>>
>> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org>:
>>
>> On Fri, Jun 10, 2016 at 6:10 AM, Karl  wrote:
>>
>>> -1
>>>
>>> * Swift is explicitly a C-family language. In most or all other C-family
>>> languages, for loop statements allow specification of conditions for
>>> exiting the loop but not for filtering. Therefore, Swift's use of `where`
>>> is unprecedented and needs to be learned anew by every user of Swift.
>>>
>>>
>>> When was this decided? I distinctly remember some bloke under Craig
>>> Federighi’s hair saying that it was time to “move beyond” C and essentially
>>> ditch legacy conventions which no longer make sense.
>>>
>>
>> I think you misunderstood my argument here. I don't mean that we should
>> yoke ourselves to C conventions, and we should absolutely ditch C
>> convention when it doesn't make sense. The big-picture argument here is
>> that `where` doesn't pass the bar of correcting a C convention that no
>> longer makes sense.
>>
>> FWIW, on the topic of syntax choices, here is what Chris Lattner had to
>> say on this list:
>>
>> Kevin got it exa*c*tly right, but I’d expand that last bit a bit to:
>>> “… pi*c*king the one that is most familiar to programmers in the
>>> extended *C* *family* is a good idea.["]
>>> The extended *C* *family* of language (whi*c*h in*c*ludes *C*, *C*++,
>>> Obj*C*, but also *C*#, Java, Javas*c*ript, and more) is
>>> an extremely popular and widely used set of languages that have a lot of
>>> surfa*c*e-level similarity. I
>>> don’t *c*laim to know the design rationale of all of these languages,
>>> but I surmise that this is not an
>>> a*c**c*ident: programmers move around and work in different languages,
>>> and this allows a non-expert in the
>>> language to understand what is going on. While there are things about
>>> *C* that are really unfortunate IMO
>>> (e.g. the de*c*larator/de*c*laration spe*c*ifier part of the grammar)
>>> there is a lot of goodness in the basi
>>> *c*operator set, fo*c*us on dot syntax, and more.
>>> I do agree that there are some benefits to dit*c*hing bra*c*es and
>>> relying on indentation instead, but there are
>>> also downsides. Deviating from the *C* *family* in this respe*c*t would
>>> have to provide **overwhelmingly** large
>>> advantages for us to take su*c*h a plunge, and they simply don’t exist.
>>
>>
>>
>>> As I understand it, Swift is a new language with new conventions. It is
>>> desirable to align as many of those as possible with existing conventions
>>> so as to be easily learned, but if you limit Swift to other languages
>>> conventions you deny it any identity. Did Python ask anybody’s opinion
>>> before dropping curly-braces? Did people learn whatever Perl is supposed to
>>> be? Look at C’s hieroglyphic for loops!
>>>
>>
>> I don't think we disagree here.
>>
>>
>>>
>>> Realistically, “for … in … while” is not going to cause incredible
>>> confusion. Removing it would cause a lot of frustration. You can’t on the
>>> one hand say our users are comfortable with the axioms of C’s hieroglyphic
>>> loops, and on the other hand say “for x in y while" is confusing.
>>>
>>> Again, as I said, once you've mastered something, by definition you find
>>> it not confusing. Why should we doom x% of new users to writing a loop
>>> incorrectly at least once when we don't have to?
>>>
>>>
>>> Ah, but if you’re not “doomed” to failing once, how will you ever master
>>> anything? Nobody knew how to write a C for-loop until someone showed them
>>> (and even then…). Nobody is going to just open a REPL and start writing
>>> code, with zero prior understanding of what Swift syntax looks like.
>>>
>>
>> The thought here is along the lines of what Chris said, quoted above, and
>> repeated here: "The extended C family of language [...] is an extremely
>> popular and widely used set[;] programmers move around and work in
>> different languages, and [aligning to expectations arising from other C
>> family languages] allows a non-expert in the language to understand what is
>> going on." By contrast, the `where` clause violates that expectation and I
>> do not see "overwhelmingly large advantages" for doing so.
>>
>>
>> What about C#'s `where` then? As C# is a member of the C family languages
>> `where` is not violating expectations!
>>
>>
>> Where is not 

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

[Xiaodi Wu via swift-evolution]

On Sun, Jun 12, 2016 at 8:28 AM, Thorsten Seitz  wrote:

>
> Am 12.06.2016 um 00:16 schrieb Xiaodi Wu :
>
> On Sat, Jun 11, 2016 at 5:07 PM, Thorsten Seitz 
> wrote:
>
>>
>>
>> Am 11.06.2016 um 23:52 schrieb Xiaodi Wu :
>>
>> On Sat, Jun 11, 2016 at 3:31 PM, Thorsten Seitz 
>> wrote:
>>
>>>
>>>
>>> Am 11.06.2016 um 21:57 schrieb Xiaodi Wu :
>>>
>>> On Sat, Jun 11, 2016 at 2:50 PM, Thorsten Seitz 
>>> wrote:
>>>


 Am 10.06.2016 um 17:22 schrieb Erica Sadun via swift-evolution <
 swift-evolution@swift.org>:


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

 On Fri, Jun 10, 2016 at 7:18 AM, Haravikk 
 wrote:

> * The word "where" does not consistently imply `break` or `continue`.
> In current Swift, `where` implies `break` in the context of a `while` loop
> and `continue` in the context of a `for` loop. Some users intuitively 
> guess
> the correct meaning in each context, while others guess the wrong meaning.
> Therefore, the only way to learn for sure what `where` means in any 
> context
> is to read the rulebook. That, by definition, means that this is
> unintuitive.
>
>
> This is an argument for renaming the where keyword on for loops to be
> more clear, or to somehow integrate continue/break to be more explicit
> about what the developer intends for it to do.
>

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


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

 One more data point.

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


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

>>>
>>> That is a different argument, I think, from the one Erica is making. The
>>> data you're asking about would answer the question, "How often do stdlib
>>> authors prefer `guard` over `where`?" That is an interesting question,
>>> certainly.
>>>
>>>
>>> It is the relevant question to ask when deciding whether `where` should
>>> be better replaced by `guard`. And it should be qualified by asking whether
>>> the respective author did know about `where`. I wouldn't want a language to
>>> be designed by looking at usage examples of inexperienced users...
>>>
>>>
>> Here, I disagree with you vehemently. We should absolutely take into
>> consideration how inexperienced users work with the language. A language
>> that ignores the struggles and pain points of those who are less
>> experienced is one that will quickly find itself lacking in users.
>>
>>
>> You don't want to tell me in earnest that discovering and understanding
>> `where` in for loops are stumbling blocks for beginners in a language
>> containing generics, associated types, existentials, value vs. reference
>> types etc.?
>>
>
> I do. I challenge you to find an introductory text that teaches generics,
> associated types, existentials, or even value vs. reference types before it
> introduces `for` loops or `if` (and `guard`).
>
>
> My point was that someone who endeavors to learn a language like Swift
> which does include all these things, will not falter when he stumbles upon
> `where` in a `for` loop.
>

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

He might be surprised for a moment (when coming from other languages but
> probably not when Swift is his first language, nor when he already knows
> languages like C# or SQL) but not more.
>
> -Thorsten
>
>
>
>
>>
>> -Thorsten
>>
>>
>>> I think Erica's point is that what Vladimir earlier called the "simple,
>>> common" case may be simple but isn't actually common. I did a quick GitHub
>>> search earlier today (and the tools aren't there, afaik, for an accurate
>>> regexp search), but what I noticed on a random, not-statistically-sound
>>> sampling was that uses of `continue` and `break`, when they do occur inside
>>> a for loop (which isn't always), actually tend to happen after 

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

[Xiaodi Wu via swift-evolution]

On Sun, Jun 12, 2016 at 7:10 AM, plx via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Jun 10, 2016, at 12:59 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Fri, Jun 10, 2016 at 12:30 PM, let var go  wrote:
>
>> I respect that anti-goal, but I think being over-rigid about limiting
>> developers' choice of expression is also an anti-goal.
>>
>> To me, it is like guard statements vs. if-let statements. Some people
>> find one to be more clear than the other. Often times the best choice
>> depends on the context. Sometimes a guard statement can be re-written as an
>> if-let statement in a way that makes the code more clear, and vice versa.
>>
>
> The comparison with `guard` and `if` is a little inapt. The introduction
> of `guard` solved a practical daily issue with `if` that was nicknamed the
> pyramid of doom, where successive `if let` statements caused code to be
> severely nested in braces and nearly unreadable. Further, you must exist
> the scope with `guard`; thus, its use signals an intention not possible
> with `if`. If, on the other hand, you do not wish to exit the scope, you
> must use `if`. So in a Venn diagram, there are independent uses for `if`
> that cannot be fulfilled by `guard`, and uses for `guard` that would be
> unreadable if rewritten with `if`.
>
>
>> And different people will inevitably have different personal preferences
>> - their own "style", if you will - and will favor one over the other. But
>> it would be a mistake to force everyone into one box in order to prevent
>> the fracturing of the Swift community into "dialects."
>>
>
>> But most importantly (and this is really the kicker for me) there are
>> times when the "where" syntax provides the maximum amount of clarity in the
>> context of my code, and I don't want to lose that expressive power.
>>
>
> This is the key and salient point here. Would you be able to share some
> examples where the `where` syntax provides a clear win in clarity? That
> would definitely be a huge pro, if it can be used to solve issues in
> expressiveness much like `guard` allowed elimination of the pyramid of doom.
>
>
> I’d hate to lose `where` in for-in loops; I use it a lot. My own 2c on it
> is that I think if you look at isolated uses of `where` it’s not adding
> much clarity, but having it can allow you to adopt more-consistent patterns
> overall…which IMHO *does* result in clearer code.
>
> I’ll provide two examples of such “consistent patterns” and how the
> presence of `for`-`in` `where` helps stick with them.
>
> First Pattern: for some simple types I like to do data-driven unit tests —
> here’s a collection of values to test, here’s a basic, “algebraic" property
> that should apply, test it actually does, and so on.
>
> When I write a set of tests like that, I like to have a single variable
> holding the “instances to test” that is shared by all relevant tests; this
> lets me start with only a handful of values, confirm it seems to work, and
> then have a single place to edit once I’m ready to expand the values we
> test upon.
>
> Such tests might wind up looking like this:
>
>   func testNaiveAncestor() {
>  // the root has no ancestor so we simply to skip it:
>  for position in testPositions where !position.isRootPosition {
> XCTAssertLessThan(
>  position.naiveAncestor(),
>  position
> )
>  }
>   }
>
>   func testNaiveSuccessor() {
>  for position in testPositions {
> XCTAssertGreaterThan(
>  position.naiveSuccessor(),
>  position
> )
>  }
>   }
>
> …where `testPositions` holds the values to test, and the two tests are
> each testing a basic algebraic property. Having `where` available on
> for-loops makes it possible to write these in such a way that the intended
> parallelism between the two is visually-apparent—you can tell they’re the
> same sort of thing just by looking at them—and it does so in a way that
> makes few assumptions on the type-or-contents of `testPositions`.
>

First, notice how your comment is related to the `where` clause but is
actually sitting on top of the loop itself. Second, one of these two tests
visits every element while the other doesn't, and it took me three reads
before I could see that because I literally couldn't find the `where`
clause the first two times I scanned through your code. This is a false
"parallelism," causing the very thing that *isn't* parallel to disappear
from the reader's eye. Compare instead this alternative, which also flips
the boolean assertion:

```
func testNaiveAncestor() {
  for position in testPositions {
// the root has no ancestor
if position.isRootPosition { continue }
// (notice how I don't even have to comment that we're skipping root,
// because the code says it explicitly for me)

XCTAssertLessThan(position.naiveAncestor(), position)
  }
}
```

Now, with my rewriting, the part of your test that is 

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

[L. Mihalkovic via swift-evolution]

> On Jun 12, 2016, at 3:21 PM, Thorsten Seitz  wrote:
> 
> 
>>> Am 12.06.2016 um 12:02 schrieb L Mihalkovic :
>>> 
>>> 
>>> On Jun 11, 2016, at 11:45 PM, Xiaodi Wu  wrote:
>>> 
>>> 
>>> 
>>> On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz  wrote:
 
 
> Am 11.06.2016 um 22:29 schrieb L. Mihalkovic 
> :
> 
> 
> 
>> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution 
>>> :
>>> 
 On Fri, Jun 10, 2016 at 6:10 AM, Karl  wrote:
 -1
 
> * Swift is explicitly a C-family language. In most or all other 
> C-family languages, for loop statements allow specification of 
> conditions for exiting the loop but not for filtering. Therefore, 
> Swift's use of `where` is unprecedented and needs to be learned anew 
> by every user of Swift.
 
 When was this decided? I distinctly remember some bloke under Craig 
 Federighi’s hair saying that it was time to “move beyond” C and 
 essentially ditch legacy conventions which no longer make sense.
>>> 
>>> I think you misunderstood my argument here. I don't mean that we should 
>>> yoke ourselves to C conventions, and we should absolutely ditch C 
>>> convention when it doesn't make sense. The big-picture argument here is 
>>> that `where` doesn't pass the bar of correcting a C convention that no 
>>> longer makes sense.
>>> 
>>> FWIW, on the topic of syntax choices, here is what Chris Lattner had to 
>>> say on this list:
>>> 
 Kevin got it exactly right, but I’d expand that last bit a bit to:
 “… picking the one that is most familiar to programmers in the 
 extended C family is a good idea.["]
 The extended C family of language (which includes C, C++, ObjC, but 
 also C#, Java, Javascript, and more) is
 an extremely popular and widely used set of languages that have a lot 
 of surface-level similarity. I
 don’t claim to know the design rationale of all of these languages, 
 but I surmise that this is not an
 accident: programmers move around and work in different languages, and 
 this allows a non-expert in the
 language to understand what is going on. While there are things about 
 C that are really unfortunate IMO
 (e.g. the declarator/declaration specifier part of the grammar) there 
 is a lot of goodness in the basic
 operator set, focus on dot syntax, and more.
 I do agree that there are some benefits to ditching braces and relying 
 on indentation instead, but there are
 also downsides. Deviating from the C family in this respect would have 
 to provide *overwhelmingly* large 
 advantages for us to take such a plunge, and they simply don’t exist.
>>>  
 As I understand it, Swift is a new language with new conventions. It 
 is desirable to align as many of those as possible with existing 
 conventions so as to be easily learned, but if you limit Swift to 
 other languages conventions you deny it any identity. Did Python ask 
 anybody’s opinion before dropping curly-braces? Did people learn 
 whatever Perl is supposed to be? Look at C’s hieroglyphic for loops! 
>>> 
>>> I don't think we disagree here.
>>>  
 
 Realistically, “for … in … while” is not going to cause incredible 
 confusion. Removing it would cause a lot of frustration. You can’t on 
 the one hand say our users are comfortable with the axioms of C’s 
 hieroglyphic loops, and on the other hand say “for x in y while" is 
 confusing.
 
> Again, as I said, once you've mastered something, by definition you 
> find it not confusing. Why should we doom x% of new users to writing 
> a loop incorrectly at least once when we don't have to?
 
 
 Ah, but if you’re not “doomed” to failing once, how will you ever 
 master anything? Nobody knew how to write a C for-loop until someone 
 showed them (and even then…). Nobody is going to just open a REPL and 
 start writing code, with zero prior understanding of what Swift syntax 
 looks like.
>>> 
>>> The thought here is along the lines of what Chris said, quoted above, 
>>> and repeated here: "The extended C family of language [...] is an 
>>> extremely popular and widely used set[;] programmers move around and 
>>> work in different languages, and [aligning to expectations arising from 
>>> other C family 

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

[Thorsten Seitz via swift-evolution]

> Am 12.06.2016 um 00:16 schrieb Xiaodi Wu :
> 
> On Sat, Jun 11, 2016 at 5:07 PM, Thorsten Seitz  > wrote:
> 
> 
> Am 11.06.2016 um 23:52 schrieb Xiaodi Wu  >:
> 
>> On Sat, Jun 11, 2016 at 3:31 PM, Thorsten Seitz > > wrote:
>> 
>> 
>> Am 11.06.2016 um 21:57 schrieb Xiaodi Wu > >:
>> 
>>> On Sat, Jun 11, 2016 at 2:50 PM, Thorsten Seitz >> > wrote:
>>> 
>>> 
>>> Am 10.06.2016 um 17:22 schrieb Erica Sadun via swift-evolution 
>>> >:
>>> 
 
> On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
> On Fri, Jun 10, 2016 at 7:18 AM, Haravikk  > wrote:
>> * The word "where" does not consistently imply `break` or `continue`. In 
>> current Swift, `where` implies `break` in the context of a `while` loop 
>> and `continue` in the context of a `for` loop. Some users intuitively 
>> guess the correct meaning in each context, while others guess the wrong 
>> meaning. Therefore, the only way to learn for sure what `where` means in 
>> any context is to read the rulebook. That, by definition, means that 
>> this is unintuitive.
> 
> This is an argument for renaming the where keyword on for loops to be 
> more clear, or to somehow integrate continue/break to be more explicit 
> about what the developer intends for it to do.
> 
> Sure: I conclude that the keyword should be *either* removed *or* 
> reformed; both outcomes could address the issue.
 
 This is my stance as well and I reserve the right to flit between both 
 choices until we've fully talked it through.
 
 One more data point. 
 
 In the standard library there are just under 950 uses of "for in loops". 
 There are 3 uses of "for in while" :
>>> 
>>> How many of the 950 "for in loops" use a guard with continue? Only these 
>>> can be compard with the "for in where loops".
>>> 
>>> That is a different argument, I think, from the one Erica is making. The 
>>> data you're asking about would answer the question, "How often do stdlib 
>>> authors prefer `guard` over `where`?" That is an interesting question, 
>>> certainly.
>> 
>> It is the relevant question to ask when deciding whether `where` should be 
>> better replaced by `guard`. And it should be qualified by asking whether the 
>> respective author did know about `where`. I wouldn't want a language to be 
>> designed by looking at usage examples of inexperienced users...
>> 
>> 
>> Here, I disagree with you vehemently. We should absolutely take into 
>> consideration how inexperienced users work with the language. A language 
>> that ignores the struggles and pain points of those who are less experienced 
>> is one that will quickly find itself lacking in users.
> 
> You don't want to tell me in earnest that discovering and understanding 
> `where` in for loops are stumbling blocks for beginners in a language 
> containing generics, associated types, existentials, value vs. reference 
> types etc.?
> 
> I do. I challenge you to find an introductory text that teaches generics, 
> associated types, existentials, or even value vs. reference types before it 
> introduces `for` loops or `if` (and `guard`).

My point was that someone who endeavors to learn a language like Swift which 
does include all these things, will not falter when he stumbles upon `where` in 
a `for` loop. He might be surprised for a moment (when coming from other 
languages but probably not when Swift is his first language, nor when he 
already knows languages like C# or SQL) but not more.

-Thorsten


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

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

[Thorsten Seitz via swift-evolution]

> Am 12.06.2016 um 12:02 schrieb L Mihalkovic :
> 
> 
>> On Jun 11, 2016, at 11:45 PM, Xiaodi Wu > > wrote:
>> 
>> 
>> 
>> On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz > > wrote:
>> 
>> 
>> Am 11.06.2016 um 22:29 schrieb L. Mihalkovic > >:
>> 
>>> 
>>> 
>>> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution 
>>> > wrote:
>>> 
 
 
 Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution 
 >:
 
> On Fri, Jun 10, 2016 at 6:10 AM, Karl  > wrote:
> -1
> 
>> * Swift is explicitly a C-family language. In most or all other C-family 
>> languages, for loop statements allow specification of conditions for 
>> exiting the loop but not for filtering. Therefore, Swift's use of 
>> `where` is unprecedented and needs to be learned anew by every user of 
>> Swift.
> 
> When was this decided? I distinctly remember some bloke under Craig 
> Federighi’s hair saying that it was time to “move beyond” C and 
> essentially ditch legacy conventions which no longer make sense.
> 
> I think you misunderstood my argument here. I don't mean that we should 
> yoke ourselves to C conventions, and we should absolutely ditch C 
> convention when it doesn't make sense. The big-picture argument here is 
> that `where` doesn't pass the bar of correcting a C convention that no 
> longer makes sense.
> 
> FWIW, on the topic of syntax choices, here is what Chris Lattner had to 
> say on this list:
> 
> Kevin got it exactly right, but I’d expand that last bit a bit to:
> “… picking the one that is most familiar to programmers in the extended C 
> family is a good idea.["]
> The extended C family of language (which includes C, C++, ObjC, but also 
> C#, Java, Javascript, and more) is
> an extremely popular and widely used set of languages that have a lot of 
> surface-level similarity. I
> don’t claim to know the design rationale of all of these languages, but I 
> surmise that this is not an
> accident: programmers move around and work in different languages, and 
> this allows a non-expert in the
> language to understand what is going on. While there are things about C 
> that are really unfortunate IMO
> (e.g. the declarator/declaration specifier part of the grammar) there is 
> a lot of goodness in the basic
> operator set, focus on dot syntax, and more.
> I do agree that there are some benefits to ditching braces and relying on 
> indentation instead, but there are
> also downsides. Deviating from the C family in this respect would have to 
> provide *overwhelmingly* large 
> advantages for us to take such a plunge, and they simply don’t exist.
>  
> As I understand it, Swift is a new language with new conventions. It is 
> desirable to align as many of those as possible with existing conventions 
> so as to be easily learned, but if you limit Swift to other languages 
> conventions you deny it any identity. Did Python ask anybody’s opinion 
> before dropping curly-braces? Did people learn whatever Perl is supposed 
> to be? Look at C’s hieroglyphic for loops! 
> 
> I don't think we disagree here.
>  
> 
> Realistically, “for … in … while” is not going to cause incredible 
> confusion. Removing it would cause a lot of frustration. You can’t on the 
> one hand say our users are comfortable with the axioms of C’s 
> hieroglyphic loops, and on the other hand say “for x in y while" is 
> confusing.
> 
>> Again, as I said, once you've mastered something, by definition you find 
>> it not confusing. Why should we doom x% of new users to writing a loop 
>> incorrectly at least once when we don't have to?
> 
> 
> Ah, but if you’re not “doomed” to failing once, how will you ever master 
> anything? Nobody knew how to write a C for-loop until someone showed them 
> (and even then…). Nobody is going to just open a REPL and start writing 
> code, with zero prior understanding of what Swift syntax looks like.
> 
> The thought here is along the lines of what Chris said, quoted above, and 
> repeated here: "The extended C family of language [...] is an extremely 
> popular and widely used set[;] programmers move around and work in 
> different languages, and [aligning to expectations arising from other C 
> family languages] allows a non-expert in the language to understand what 
> is going on." By contrast, the `where` clause violates that 

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

[Brandon Knope via swift-evolution]

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

Brandon

Sent from my iPad

> On Jun 12, 2016, at 6:02 AM, L Mihalkovic via swift-evolution 
>  wrote:
> 
> 
>> On Jun 11, 2016, at 11:45 PM, Xiaodi Wu  wrote:
>> 
>> 
>> 
>> On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz  wrote:
>>> 
>>> 
 Am 11.06.2016 um 22:29 schrieb L. Mihalkovic 
 :
 
 
 
> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
> 
>> Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution 
>> :
>> 
>>> On Fri, Jun 10, 2016 at 6:10 AM, Karl  wrote:
>>> -1
>>> 
 * Swift is explicitly a C-family language. In most or all other 
 C-family languages, for loop statements allow specification of 
 conditions for exiting the loop but not for filtering. Therefore, 
 Swift's use of `where` is unprecedented and needs to be learned anew 
 by every user of Swift.
>>> 
>>> When was this decided? I distinctly remember some bloke under Craig 
>>> Federighi’s hair saying that it was time to “move beyond” C and 
>>> essentially ditch legacy conventions which no longer make sense.
>> 
>> I think you misunderstood my argument here. I don't mean that we should 
>> yoke ourselves to C conventions, and we should absolutely ditch C 
>> convention when it doesn't make sense. The big-picture argument here is 
>> that `where` doesn't pass the bar of correcting a C convention that no 
>> longer makes sense.
>> 
>> FWIW, on the topic of syntax choices, here is what Chris Lattner had to 
>> say on this list:
>> 
>>> Kevin got it exactly right, but I’d expand that last bit a bit to:
>>> “… picking the one that is most familiar to programmers in the extended 
>>> C family is a good idea.["]
>>> The extended C family of language (which includes C, C++, ObjC, but 
>>> also C#, Java, Javascript, and more) is
>>> an extremely popular and widely used set of languages that have a lot 
>>> of surface-level similarity. I
>>> don’t claim to know the design rationale of all of these languages, but 
>>> I surmise that this is not an
>>> accident: programmers move around and work in different languages, and 
>>> this allows a non-expert in the
>>> language to understand what is going on. While there are things about C 
>>> that are really unfortunate IMO
>>> (e.g. the declarator/declaration specifier part of the grammar) there 
>>> is a lot of goodness in the basic
>>> operator set, focus on dot syntax, and more.
>>> I do agree that there are some benefits to ditching braces and relying 
>>> on indentation instead, but there are
>>> also downsides. Deviating from the C family in this respect would have 
>>> to provide *overwhelmingly* large 
>>> advantages for us to take such a plunge, and they simply don’t exist.
>>  
>>> As I understand it, Swift is a new language with new conventions. It is 
>>> desirable to align as many of those as possible with existing 
>>> conventions so as to be easily learned, but if you limit Swift to other 
>>> languages conventions you deny it any identity. Did Python ask 
>>> anybody’s opinion before dropping curly-braces? Did people learn 
>>> whatever Perl is supposed to be? Look at C’s hieroglyphic for loops! 
>> 
>> I don't think we disagree here.
>>  
>>> 
>>> Realistically, “for … in … while” is not going to cause incredible 
>>> confusion. Removing it would cause a lot of frustration. You can’t on 
>>> the one hand say our users are comfortable with the axioms of C’s 
>>> hieroglyphic loops, and on the other hand say “for x in y while" is 
>>> confusing.
>>> 
 Again, as I said, once you've mastered something, by definition you 
 find it not confusing. Why should we doom x% of new users to writing a 
 loop incorrectly at least once when we don't have to?
>>> 
>>> 
>>> Ah, but if you’re not “doomed” to failing once, how will you ever 
>>> master anything? Nobody knew how to write a C for-loop until someone 
>>> showed them (and even then…). Nobody is going to just open a REPL and 
>>> start writing code, with zero prior understanding of what Swift syntax 
>>> looks like.
>> 
>> The thought here is along the lines of what Chris said, quoted above, 
>> and repeated here: "The extended C family of language [...] is an 
>> extremely popular and widely used set[;] programmers move around and 
>> work in different languages, and [aligning to expectations arising from 
>> other C family languages] allows a non-expert in the language to 
>> understand 

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

[plx via swift-evolution]

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

I’d hate to lose `where` in for-in loops; I use it a lot. My own 2c on it is 
that I think if you look at isolated uses of `where` it’s not adding much 
clarity, but having it can allow you to adopt more-consistent patterns 
overall…which IMHO *does* result in clearer code.

I’ll provide two examples of such “consistent patterns” and how the presence of 
`for`-`in` `where` helps stick with them.

First Pattern: for some simple types I like to do data-driven unit tests — 
here’s a collection of values to test, here’s a basic, “algebraic" property 
that should apply, test it actually does, and so on.

When I write a set of tests like that, I like to have a single variable holding 
the “instances to test” that is shared by all relevant tests; this lets me 
start with only a handful of values, confirm it seems to work, and then have a 
single place to edit once I’m ready to expand the values we test upon.

Such tests might wind up looking like this:

  func testNaiveAncestor() {
 // the root has no ancestor so we simply to skip it:
 for position in testPositions where !position.isRootPosition {
XCTAssertLessThan(
 position.naiveAncestor(), 
 position
)
 }
  }

  func testNaiveSuccessor() {
 for position in testPositions {
XCTAssertGreaterThan(
 position.naiveSuccessor(), 
 position
)
 }
  }

…where `testPositions` holds the values to test, and the two tests are each 
testing a basic algebraic property. Having `where` available on for-loops makes 
it possible to write these in such a way that the intended parallelism between 
the two is visually-apparent—you can tell they’re the same sort of thing just 
by looking at them—and it does so in a way that makes few assumptions on the 
type-or-contents of `testPositions`. 

So `where` here, IMHO, isn’t *clearly* clearer in `testNaiveAncestor()`, but it 
lets `testNaiveAncestor()` and `testNaiveSuccessor()` (etc.) be 
*systemically*-clearer, as it were.

Second Pattern: relatedly, I find code is much clearer when `guard` is 
only-ever used for early exits and early returns. 

There’s no requirement to *not* use `guard` and `continue` together, but if one 
is willing to stick to `guard` == “early exit / early return” it makes code 
much easier to read and audit.

In a handful of places I have for loops that would need both `continue`-style 
conditionals and also early-exit conditionals; having `where` means I can stick 
to using `guard` for early-exits, whereas without it I’d have extra nesting or 
mixed “early-exit” guard and “continue” guard. 

This is as short as I can make it:

  /// Returns the portion of our frame that *might* be visible on-screen; 
doesn't
  /// handle occlusion, but unlike `approximateWindowRegion` will account for 
  /// clipping done by our superviews.
  ///
  /// - note: 

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

[L Mihalkovic via swift-evolution]

> On Jun 11, 2016, at 11:45 PM, Xiaodi Wu  wrote:
> 
> 
> 
> On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz  > wrote:
> 
> 
> Am 11.06.2016 um 22:29 schrieb L. Mihalkovic  >:
> 
>> 
>> 
>> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
>>> Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution 
>>> >:
>>> 
 On Fri, Jun 10, 2016 at 6:10 AM, Karl > wrote:
 -1
 
> * Swift is explicitly a C-family language. In most or all other C-family 
> languages, for loop statements allow specification of conditions for 
> exiting the loop but not for filtering. Therefore, Swift's use of `where` 
> is unprecedented and needs to be learned anew by every user of Swift.
 
 When was this decided? I distinctly remember some bloke under Craig 
 Federighi’s hair saying that it was time to “move beyond” C and 
 essentially ditch legacy conventions which no longer make sense.
 
 I think you misunderstood my argument here. I don't mean that we should 
 yoke ourselves to C conventions, and we should absolutely ditch C 
 convention when it doesn't make sense. The big-picture argument here is 
 that `where` doesn't pass the bar of correcting a C convention that no 
 longer makes sense.
 
 FWIW, on the topic of syntax choices, here is what Chris Lattner had to 
 say on this list:
 
 Kevin got it exactly right, but I’d expand that last bit a bit to:
 “… picking the one that is most familiar to programmers in the extended C 
 family is a good idea.["]
 The extended C family of language (which includes C, C++, ObjC, but also 
 C#, Java, Javascript, and more) is
 an extremely popular and widely used set of languages that have a lot of 
 surface-level similarity. I
 don’t claim to know the design rationale of all of these languages, but I 
 surmise that this is not an
 accident: programmers move around and work in different languages, and 
 this allows a non-expert in the
 language to understand what is going on. While there are things about C 
 that are really unfortunate IMO
 (e.g. the declarator/declaration specifier part of the grammar) there is a 
 lot of goodness in the basic
 operator set, focus on dot syntax, and more.
 I do agree that there are some benefits to ditching braces and relying on 
 indentation instead, but there are
 also downsides. Deviating from the C family in this respect would have to 
 provide *overwhelmingly* large 
 advantages for us to take such a plunge, and they simply don’t exist.
  
 As I understand it, Swift is a new language with new conventions. It is 
 desirable to align as many of those as possible with existing conventions 
 so as to be easily learned, but if you limit Swift to other languages 
 conventions you deny it any identity. Did Python ask anybody’s opinion 
 before dropping curly-braces? Did people learn whatever Perl is supposed 
 to be? Look at C’s hieroglyphic for loops! 
 
 I don't think we disagree here.
  
 
 Realistically, “for … in … while” is not going to cause incredible 
 confusion. Removing it would cause a lot of frustration. You can’t on the 
 one hand say our users are comfortable with the axioms of C’s hieroglyphic 
 loops, and on the other hand say “for x in y while" is confusing.
 
> Again, as I said, once you've mastered something, by definition you find 
> it not confusing. Why should we doom x% of new users to writing a loop 
> incorrectly at least once when we don't have to?
 
 
 Ah, but if you’re not “doomed” to failing once, how will you ever master 
 anything? Nobody knew how to write a C for-loop until someone showed them 
 (and even then…). Nobody is going to just open a REPL and start writing 
 code, with zero prior understanding of what Swift syntax looks like.
 
 The thought here is along the lines of what Chris said, quoted above, and 
 repeated here: "The extended C family of language [...] is an extremely 
 popular and widely used set[;] programmers move around and work in 
 different languages, and [aligning to expectations arising from other C 
 family languages] allows a non-expert in the language to understand what 
 is going on." By contrast, the `where` clause violates that expectation 
 and I do not see "overwhelmingly large advantages" for doing so.
>>> 
>>> What about C#'s `where` then? As C# is a member of the C family languages 
>>> `where` is not violating expectations!
>> 
>> Where is not 

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

[Xiaodi Wu via swift-evolution]

On Sat, Jun 11, 2016 at 5:07 PM, Thorsten Seitz  wrote:

>
>
> Am 11.06.2016 um 23:52 schrieb Xiaodi Wu :
>
> On Sat, Jun 11, 2016 at 3:31 PM, Thorsten Seitz 
> wrote:
>
>>
>>
>> Am 11.06.2016 um 21:57 schrieb Xiaodi Wu :
>>
>> On Sat, Jun 11, 2016 at 2:50 PM, Thorsten Seitz 
>> wrote:
>>
>>>
>>>
>>> Am 10.06.2016 um 17:22 schrieb Erica Sadun via swift-evolution <
>>> swift-evolution@swift.org>:
>>>
>>>
>>> On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On Fri, Jun 10, 2016 at 7:18 AM, Haravikk 
>>> wrote:
>>>
 * The word "where" does not consistently imply `break` or `continue`.
 In current Swift, `where` implies `break` in the context of a `while` loop
 and `continue` in the context of a `for` loop. Some users intuitively guess
 the correct meaning in each context, while others guess the wrong meaning.
 Therefore, the only way to learn for sure what `where` means in any context
 is to read the rulebook. That, by definition, means that this is
 unintuitive.


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

>>>
>>> Sure: I conclude that the keyword should be *either* removed *or*
>>> reformed; both outcomes could address the issue.
>>>
>>>
>>> This is my stance as well and I reserve the right to flit between both
>>> choices until we've fully talked it through.
>>>
>>> One more data point.
>>>
>>> In the standard library there are just under 950 uses of "for in loops".
>>> There are 3 uses of "for in while" :
>>>
>>>
>>> How many of the 950 "for in loops" use a guard with continue? Only these
>>> can be compard with the "for in where loops".
>>>
>>
>> That is a different argument, I think, from the one Erica is making. The
>> data you're asking about would answer the question, "How often do stdlib
>> authors prefer `guard` over `where`?" That is an interesting question,
>> certainly.
>>
>>
>> It is the relevant question to ask when deciding whether `where` should
>> be better replaced by `guard`. And it should be qualified by asking whether
>> the respective author did know about `where`. I wouldn't want a language to
>> be designed by looking at usage examples of inexperienced users...
>>
>>
> Here, I disagree with you vehemently. We should absolutely take into
> consideration how inexperienced users work with the language. A language
> that ignores the struggles and pain points of those who are less
> experienced is one that will quickly find itself lacking in users.
>
>
> You don't want to tell me in earnest that discovering and understanding
> `where` in for loops are stumbling blocks for beginners in a language
> containing generics, associated types, existentials, value vs. reference
> types etc.?
>

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


>
> -Thorsten
>
>
>> I think Erica's point is that what Vladimir earlier called the "simple,
>> common" case may be simple but isn't actually common. I did a quick GitHub
>> search earlier today (and the tools aren't there, afaik, for an accurate
>> regexp search), but what I noticed on a random, not-statistically-sound
>> sampling was that uses of `continue` and `break`, when they do occur inside
>> a for loop (which isn't always), actually tend to happen after some work
>> has been done at the top of the loop. These wouldn't be replaceable by a
>> `where` clause. Moreover, I noticed an appreciable share of `return` and
>> `fatalError()` calls from inside the loop, which surprised me; I had
>> assumed I'd find mostly `break` or `continue`, but even when I did find
>> those it was as likely as not to be accompanied by logging. These again
>> preclude refactoring into `where`.
>>
>>
>> Logging hints at logic used for filtering out data errors. That's a good
>> usage for `guard` as opposed to `where`. The latter is about logic, not
>> about error handling.
>>
>> -Thorsten
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Sat, Jun 11, 2016 at 5:03 PM, Thorsten Seitz  wrote:

>
>
> Am 11.06.2016 um 23:45 schrieb Xiaodi Wu :
>
>
>
> On Sat, Jun 11, 2016 at 3:37 PM, Thorsten Seitz 
> wrote:
>
>>
>>
>> Am 11.06.2016 um 22:29 schrieb L. Mihalkovic <
>> laurent.mihalko...@gmail.com>:
>>
>>
>>
>> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org>:
>>
>> On Fri, Jun 10, 2016 at 6:10 AM, Karl  wrote:
>>
>>> -1
>>>
>>> * Swift is explicitly a C-family language. In most or all other C-family
>>> languages, for loop statements allow specification of conditions for
>>> exiting the loop but not for filtering. Therefore, Swift's use of `where`
>>> is unprecedented and needs to be learned anew by every user of Swift.
>>>
>>>
>>> When was this decided? I distinctly remember some bloke under Craig
>>> Federighi’s hair saying that it was time to “move beyond” C and essentially
>>> ditch legacy conventions which no longer make sense.
>>>
>>
>> I think you misunderstood my argument here. I don't mean that we should
>> yoke ourselves to C conventions, and we should absolutely ditch C
>> convention when it doesn't make sense. The big-picture argument here is
>> that `where` doesn't pass the bar of correcting a C convention that no
>> longer makes sense.
>>
>> FWIW, on the topic of syntax choices, here is what Chris Lattner had to
>> say on this list:
>>
>> Kevin got it exa*c*tly right, but I’d expand that last bit a bit to:
>>> “… pi*c*king the one that is most familiar to programmers in the
>>> extended *C* *family* is a good idea.["]
>>> The extended *C* *family* of language (whi*c*h in*c*ludes *C*, *C*++,
>>> Obj*C*, but also *C*#, Java, Javas*c*ript, and more) is
>>> an extremely popular and widely used set of languages that have a lot of
>>> surfa*c*e-level similarity. I
>>> don’t *c*laim to know the design rationale of all of these languages,
>>> but I surmise that this is not an
>>> a*c**c*ident: programmers move around and work in different languages,
>>> and this allows a non-expert in the
>>> language to understand what is going on. While there are things about
>>> *C* that are really unfortunate IMO
>>> (e.g. the de*c*larator/de*c*laration spe*c*ifier part of the grammar)
>>> there is a lot of goodness in the basi
>>> *c*operator set, fo*c*us on dot syntax, and more.
>>> I do agree that there are some benefits to dit*c*hing bra*c*es and
>>> relying on indentation instead, but there are
>>> also downsides. Deviating from the *C* *family* in this respe*c*t would
>>> have to provide **overwhelmingly** large
>>> advantages for us to take su*c*h a plunge, and they simply don’t exist.
>>
>>
>>
>>> As I understand it, Swift is a new language with new conventions. It is
>>> desirable to align as many of those as possible with existing conventions
>>> so as to be easily learned, but if you limit Swift to other languages
>>> conventions you deny it any identity. Did Python ask anybody’s opinion
>>> before dropping curly-braces? Did people learn whatever Perl is supposed to
>>> be? Look at C’s hieroglyphic for loops!
>>>
>>
>> I don't think we disagree here.
>>
>>
>>>
>>> Realistically, “for … in … while” is not going to cause incredible
>>> confusion. Removing it would cause a lot of frustration. You can’t on the
>>> one hand say our users are comfortable with the axioms of C’s hieroglyphic
>>> loops, and on the other hand say “for x in y while" is confusing.
>>>
>>> Again, as I said, once you've mastered something, by definition you find
>>> it not confusing. Why should we doom x% of new users to writing a loop
>>> incorrectly at least once when we don't have to?
>>>
>>>
>>> Ah, but if you’re not “doomed” to failing once, how will you ever master
>>> anything? Nobody knew how to write a C for-loop until someone showed them
>>> (and even then…). Nobody is going to just open a REPL and start writing
>>> code, with zero prior understanding of what Swift syntax looks like.
>>>
>>
>> The thought here is along the lines of what Chris said, quoted above, and
>> repeated here: "The extended C family of language [...] is an extremely
>> popular and widely used set[;] programmers move around and work in
>> different languages, and [aligning to expectations arising from other C
>> family languages] allows a non-expert in the language to understand what is
>> going on." By contrast, the `where` clause violates that expectation and I
>> do not see "overwhelmingly large advantages" for doing so.
>>
>>
>> What about C#'s `where` then? As C# is a member of the C family languages
>> `where` is not violating expectations!
>>
>>
>> Where is not exactly a part of c# it belongs to linq
>>
>>
>> And that is not a part of C#??
>>
>
> SQL is a domain-specific language, and LINQ is an internal domain-specific
> language with a 

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

[Thorsten Seitz via swift-evolution]

> Am 11.06.2016 um 23:52 schrieb Xiaodi Wu :
> 
>> On Sat, Jun 11, 2016 at 3:31 PM, Thorsten Seitz  wrote:
>> 
>> 
>>> Am 11.06.2016 um 21:57 schrieb Xiaodi Wu :
>>> 
 On Sat, Jun 11, 2016 at 2:50 PM, Thorsten Seitz  
 wrote:
 
 
> Am 10.06.2016 um 17:22 schrieb Erica Sadun via swift-evolution 
> :
> 
> 
>> On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> On Fri, Jun 10, 2016 at 7:18 AM, Haravikk  
>> wrote:
 * The word "where" does not consistently imply `break` or `continue`. 
 In current Swift, `where` implies `break` in the context of a `while` 
 loop and `continue` in the context of a `for` loop. Some users 
 intuitively guess the correct meaning in each context, while others 
 guess the wrong meaning. Therefore, the only way to learn for sure 
 what `where` means in any context is to read the rulebook. That, by 
 definition, means that this is unintuitive.
>>> 
>>> This is an argument for renaming the where keyword on for loops to be 
>>> more clear, or to somehow integrate continue/break to be more explicit 
>>> about what the developer intends for it to do.
>> 
>> Sure: I conclude that the keyword should be *either* removed *or* 
>> reformed; both outcomes could address the issue.
> 
> This is my stance as well and I reserve the right to flit between both 
> choices until we've fully talked it through.
> 
> One more data point. 
> 
> In the standard library there are just under 950 uses of "for in loops". 
> There are 3 uses of "for in while" :
 
 How many of the 950 "for in loops" use a guard with continue? Only these 
 can be compard with the "for in where loops".
>>> 
>>> That is a different argument, I think, from the one Erica is making. The 
>>> data you're asking about would answer the question, "How often do stdlib 
>>> authors prefer `guard` over `where`?" That is an interesting question, 
>>> certainly.
>> 
>> It is the relevant question to ask when deciding whether `where` should be 
>> better replaced by `guard`. And it should be qualified by asking whether the 
>> respective author did know about `where`. I wouldn't want a language to be 
>> designed by looking at usage examples of inexperienced users...
> 
> Here, I disagree with you vehemently. We should absolutely take into 
> consideration how inexperienced users work with the language. A language that 
> ignores the struggles and pain points of those who are less experienced is 
> one that will quickly find itself lacking in users.

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

-Thorsten 

>>> 
>>> I think Erica's point is that what Vladimir earlier called the "simple, 
>>> common" case may be simple but isn't actually common. I did a quick GitHub 
>>> search earlier today (and the tools aren't there, afaik, for an accurate 
>>> regexp search), but what I noticed on a random, not-statistically-sound 
>>> sampling was that uses of `continue` and `break`, when they do occur inside 
>>> a for loop (which isn't always), actually tend to happen after some work 
>>> has been done at the top of the loop. These wouldn't be replaceable by a 
>>> `where` clause. Moreover, I noticed an appreciable share of `return` and 
>>> `fatalError()` calls from inside the loop, which surprised me; I had 
>>> assumed I'd find mostly `break` or `continue`, but even when I did find 
>>> those it was as likely as not to be accompanied by logging. These again 
>>> preclude refactoring into `where`.
>> 
>> Logging hints at logic used for filtering out data errors. That's a good 
>> usage for `guard` as opposed to `where`. The latter is about logic, not 
>> about error handling. 
>> 
>> -Thorsten 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution