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

[L_Mihalkovic]

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

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

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

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

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 '

···

On Jun 14, 2016, at 7:01 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:

On Jun 13, 2016, at 9:59 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

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

[plx]

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:

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

···

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:

-- E

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

[L_Mihalkovic]

Regards
(From mobile)

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

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

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

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.

···

On Jun 14, 2016, at 7:01 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:

On Jun 13, 2016, at 9:59 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

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

[Jean-Daniel1 (Jean-Daniel)]

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.

···

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

[Panajev (Goffredo Marocchi)]

It would not be like going back to Windows 95... and I did not mention the
infamous OSR3 release to make that harsh of a point :P...

···

On Fri, Jun 10, 2016 at 8:09 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

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

I was not advocating the lack of constraints, programmers like all other
artists (and engineers, which are artists too ;)), but that the beauty is
the moderation of the two extremes :). ... and that architects leave the
problems you are talking about to the structural engineer :P.

Gravity is a constrain, but a different one than having to use only a
certain pencil to do your sketches with and only being able to use Windows
95 OSR 3 to work on or even weirder limitations.

The question is, does removing `where` feel to you like going from OS X
10.11 to Windows 95, or is it more like going from OS X 10.11.4 to OS X
10.11.3?

On Fri, Jun 10, 2016 at 7:59 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

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

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

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

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

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

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

Sent from my iPhone

On 10 Jun 2016, at 18:30, let var go via swift-evolution < >>>> swift-evolution@swift.org> wrote:

I respect that anti-goal, but I think being over-rigid about limiting
developers' choice of expression is also an anti-goal.

To me, it is like guard statements vs. if-let statements. Some people
find one to be more clear than the other. Often times the best choice
depends on the context. Sometimes a guard statement can be re-written as an
if-let statement in a way that makes the code more clear, and vice versa.
And different people will inevitably have different personal preferences -
their own "style", if you will - and will favor one over the other. But it
would be a mistake to force everyone into one box in order to prevent the
fracturing of the Swift community into "dialects."

But most importantly (and this is really the kicker for me) there are
times when the "where" syntax provides the maximum amount of clarity in the
context of my code, and I don't want to lose that expressive power.

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

I think this idea--if you don't like it, then you don't have to use
it--is indicative of a key worry here: it's inessential to the language and
promotes dialects wherein certain people use it and others wherein they
don't. This is an anti-goal.

On Fri, Jun 10, 2016 at 12:10 let var go <letvargo@gmail.com> wrote:

Leave it in!

It's a great little tool. I don't use it very often, but when I do it
is because I've decided that in the context of that piece of code it does
exactly what I want it to do with the maximum amount of clarity.

If you don't like it, then don't use it, but I can't see how it
detracts from the language at all.

The *only* argument that I have heard for removing it is that some
people don't immediately intuit how to use it. I didn't have any trouble
with it at all. It follows one of the most basic programming patterns ever:
"For all x in X, if predicate P is true, do something." The use of the
keyword "where" makes perfect sense in that context, and when I read it out
loud, it sounds natural: "For all x in X where P, do something." That is an
elegant, succinct, and clear way of stating exactly what I want my program
to do.

I don't doubt that it has caused some confusion for some people, but
I'm not sold that that is a good enough reason to get rid of it. It seems
strange to get rid of a tool because not everyone understands how to use it
immediately, without ever having to ask a single question. As long as its
not a dangerous tool (and it isn't), then keep it in the workshop for those
times when it comes in handy. And even if there is some initial confusion,
it doesn't sound like it lasted that long. It's more like, "Does this work
like X, or does this work like Y? Let's see...oh, it works like X. Ok."
That's the entire learning curve...about 5 seconds of curiosity followed by
the blissful feeling of resolution.

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

On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>>>>> swift-evolution@swift.org> wrote:

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

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

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

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

That is worrying if true, because it suggests that it's enabling
'dialects' of Swift, an explicit anti-goal of the language.

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

l8r
Sean

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

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

_______________________________________________

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

[xwu (Xiaodi Wu)]

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

[xwu (Xiaodi Wu)]

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 <letvargo@gmail.com> 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 <xiaodi.wu@gmail.com> wrote:

On Mon, Jun 13, 2016 at 10:44 AM, let var go <letvargo@gmail.com> 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 <xiaodi.wu@gmail.com> wrote:

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

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

--1

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

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

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

I think this idea--if you don't like it, then you don't have to use
it--is indicative of a key worry here: it's inessential to the language and
promotes dialects wherein certain people use it and others wherein they
don't. This is an anti-goal.

On Fri, Jun 10, 2016 at 12:10 let var go <letvargo@gmail.com> wrote:

Leave it in!

It's a great little tool. I don't use it very often, but when I do it
is because I've decided that in the context of that piece of code it does
exactly what I want it to do with the maximum amount of clarity.

If you don't like it, then don't use it, but I can't see how it
detracts from the language at all.

The *only* argument that I have heard for removing it is that some
people don't immediately intuit how to use it. I didn't have any trouble
with it at all. It follows one of the most basic programming patterns ever:
"For all x in X, if predicate P is true, do something." The use of the
keyword "where" makes perfect sense in that context, and when I read it out
loud, it sounds natural: "For all x in X where P, do something." That is an
elegant, succinct, and clear way of stating exactly what I want my program
to do.

I don't doubt that it has caused some confusion for some people, but
I'm not sold that that is a good enough reason to get rid of it. It seems
strange to get rid of a tool because not everyone understands how to use it
immediately, without ever having to ask a single question. As long as its
not a dangerous tool (and it isn't), then keep it in the workshop for those
times when it comes in handy. And even if there is some initial confusion,
it doesn't sound like it lasted that long. It's more like, "Does this work
like X, or does this work like Y? Let's see...oh, it works like X. Ok."
That's the entire learning curve...about 5 seconds of curiosity followed by
the blissful feeling of resolution.

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

On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>>>>> swift-evolution@swift.org> wrote:

> And to follow-up to myself once again, I went to my "Cool 3rd Party

Swift Repos" folder and did the same search. Among the 15 repos in that
folder, a joint search returned about 650 hits on for-in (again with some
false positives) and not a single for-in-while use.

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

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

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

That is worrying if true, because it suggests that it's enabling
'dialects' of Swift, an explicit anti-goal of the language.

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

l8r
Sean

_______________________________________________

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

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

_______________________________________________

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

[let_var_go]

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 9:04 AM Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

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

On Mon, Jun 13, 2016 at 10:44 AM, let var go <letvargo@gmail.com> 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 <xiaodi.wu@gmail.com> wrote:

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

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

--1

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

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

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

I think this idea--if you don't like it, then you don't have to use
it--is indicative of a key worry here: it's inessential to the language and
promotes dialects wherein certain people use it and others wherein they
don't. This is an anti-goal.

On Fri, Jun 10, 2016 at 12:10 let var go <letvargo@gmail.com> wrote:

Leave it in!

It's a great little tool. I don't use it very often, but when I do it
is because I've decided that in the context of that piece of code it does
exactly what I want it to do with the maximum amount of clarity.

If you don't like it, then don't use it, but I can't see how it
detracts from the language at all.

The *only* argument that I have heard for removing it is that some
people don't immediately intuit how to use it. I didn't have any trouble
with it at all. It follows one of the most basic programming patterns ever:
"For all x in X, if predicate P is true, do something." The use of the
keyword "where" makes perfect sense in that context, and when I read it out
loud, it sounds natural: "For all x in X where P, do something." That is an
elegant, succinct, and clear way of stating exactly what I want my program
to do.

I don't doubt that it has caused some confusion for some people, but
I'm not sold that that is a good enough reason to get rid of it. It seems
strange to get rid of a tool because not everyone understands how to use it
immediately, without ever having to ask a single question. As long as its
not a dangerous tool (and it isn't), then keep it in the workshop for those
times when it comes in handy. And even if there is some initial confusion,
it doesn't sound like it lasted that long. It's more like, "Does this work
like X, or does this work like Y? Let's see...oh, it works like X. Ok."
That's the entire learning curve...about 5 seconds of curiosity followed by
the blissful feeling of resolution.

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

On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>>>>> swift-evolution@swift.org> wrote:

> And to follow-up to myself once again, I went to my "Cool 3rd Party

Swift Repos" folder and did the same search. Among the 15 repos in that
folder, a joint search returned about 650 hits on for-in (again with some
false positives) and not a single for-in-while use.

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

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

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

That is worrying if true, because it suggests that it's enabling
'dialects' of Swift, an explicit anti-goal of the language.

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

l8r
Sean

_______________________________________________

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

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

_______________________________________________

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

[Charlie_Monroe1 (Charlie Monroe)]

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 Swift.org - Documentation

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

[Erica_Sadun]

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

···

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.

[xwu (Xiaodi Wu)]

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:

Comparison of programming languages (list comprehension) - Wikipedia

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

[Dany_St-Amant]

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

···

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.

[xwu (Xiaodi Wu)]

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.

···

On Mon, Jun 13, 2016 at 11:41 AM, let var go <letvargo@gmail.com> wrote:

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

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 <xiaodi.wu@gmail.com> wrote:

On Mon, Jun 13, 2016 at 10:44 AM, let var go <letvargo@gmail.com> 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 <xiaodi.wu@gmail.com> wrote:

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

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

--1

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

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

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

I think this idea--if you don't like it, then you don't have to use
it--is indicative of a key worry here: it's inessential to the language and
promotes dialects wherein certain people use it and others wherein they
don't. This is an anti-goal.

On Fri, Jun 10, 2016 at 12:10 let var go <letvargo@gmail.com> wrote:

Leave it in!

It's a great little tool. I don't use it very often, but when I do
it is because I've decided that in the context of that piece of code it
does exactly what I want it to do with the maximum amount of clarity.

If you don't like it, then don't use it, but I can't see how it
detracts from the language at all.

The *only* argument that I have heard for removing it is that some
people don't immediately intuit how to use it. I didn't have any trouble
with it at all. It follows one of the most basic programming patterns ever:
"For all x in X, if predicate P is true, do something." The use of the
keyword "where" makes perfect sense in that context, and when I read it out
loud, it sounds natural: "For all x in X where P, do something." That is an
elegant, succinct, and clear way of stating exactly what I want my program
to do.

I don't doubt that it has caused some confusion for some people, but
I'm not sold that that is a good enough reason to get rid of it. It seems
strange to get rid of a tool because not everyone understands how to use it
immediately, without ever having to ask a single question. As long as its
not a dangerous tool (and it isn't), then keep it in the workshop for those
times when it comes in handy. And even if there is some initial confusion,
it doesn't sound like it lasted that long. It's more like, "Does this work
like X, or does this work like Y? Let's see...oh, it works like X. Ok."
That's the entire learning curve...about 5 seconds of curiosity followed by
the blissful feeling of resolution.

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

On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>>>>>> swift-evolution@swift.org> wrote:

> And to follow-up to myself once again, I went to my "Cool 3rd

Party Swift Repos" folder and did the same search. Among the 15 repos in
that folder, a joint search returned about 650 hits on for-in (again with
some false positives) and not a single for-in-while use.

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

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

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

That is worrying if true, because it suggests that it's enabling
'dialects' of Swift, an explicit anti-goal of the language.

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

l8r
Sean

_______________________________________________

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

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

_______________________________________________

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

[let_var_go]

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 <xiaodi.wu@gmail.com> 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 <letvargo@gmail.com> 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 <xiaodi.wu@gmail.com> wrote:

On Mon, Jun 13, 2016 at 10:44 AM, let var go <letvargo@gmail.com> 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 <xiaodi.wu@gmail.com> wrote:

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

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

--1

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

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

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

I think this idea--if you don't like it, then you don't have to use
it--is indicative of a key worry here: it's inessential to the language and
promotes dialects wherein certain people use it and others wherein they
don't. This is an anti-goal.

On Fri, Jun 10, 2016 at 12:10 let var go <letvargo@gmail.com> wrote:

Leave it in!

It's a great little tool. I don't use it very often, but when I do
it is because I've decided that in the context of that piece of code it
does exactly what I want it to do with the maximum amount of clarity.

If you don't like it, then don't use it, but I can't see how it
detracts from the language at all.

The *only* argument that I have heard for removing it is that some
people don't immediately intuit how to use it. I didn't have any trouble
with it at all. It follows one of the most basic programming patterns ever:
"For all x in X, if predicate P is true, do something." The use of the
keyword "where" makes perfect sense in that context, and when I read it out
loud, it sounds natural: "For all x in X where P, do something." That is an
elegant, succinct, and clear way of stating exactly what I want my program
to do.

I don't doubt that it has caused some confusion for some people, but
I'm not sold that that is a good enough reason to get rid of it. It seems
strange to get rid of a tool because not everyone understands how to use it
immediately, without ever having to ask a single question. As long as its
not a dangerous tool (and it isn't), then keep it in the workshop for those
times when it comes in handy. And even if there is some initial confusion,
it doesn't sound like it lasted that long. It's more like, "Does this work
like X, or does this work like Y? Let's see...oh, it works like X. Ok."
That's the entire learning curve...about 5 seconds of curiosity followed by
the blissful feeling of resolution.

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

On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>>>>>> swift-evolution@swift.org> wrote:

> And to follow-up to myself once again, I went to my "Cool 3rd

Party Swift Repos" folder and did the same search. Among the 15 repos in
that folder, a joint search returned about 650 hits on for-in (again with
some false positives) and not a single for-in-while use.

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

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

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

That is worrying if true, because it suggests that it's enabling
'dialects' of Swift, an explicit anti-goal of the language.

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

l8r
Sean

_______________________________________________

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

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

_______________________________________________

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

[xwu (Xiaodi Wu)]

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

The Swift Programming Language: Redirect
and the ePub download on
Swift.org - Documentation

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

[L_Mihalkovic]

Regards
(From mobile)

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
The Swift Programming Language: Redirect
and the ePub download on Swift.org - Documentation

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.

···

On Jun 14, 2016, at 8:41 AM, Charlie Monroe <charlie@charliemonroe.net> wrote:

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

[VladimirS (Vladimir)]

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

[xwu (Xiaodi Wu)]

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

:)

···

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:

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

[xwu (Xiaodi Wu)]

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 11:50 AM, let var go <letvargo@gmail.com> wrote:

On Mon, Jun 13, 2016 at 9:29 AM Xiaodi Wu <xiaodi.wu@gmail.com> 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 <letvargo@gmail.com> 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 <xiaodi.wu@gmail.com> wrote:

On Mon, Jun 13, 2016 at 10:44 AM, let var go <letvargo@gmail.com> >>>> 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 <xiaodi.wu@gmail.com> wrote:

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

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

--1

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

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

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

I think this idea--if you don't like it, then you don't have to use
it--is indicative of a key worry here: it's inessential to the language and
promotes dialects wherein certain people use it and others wherein they
don't. This is an anti-goal.

On Fri, Jun 10, 2016 at 12:10 let var go <letvargo@gmail.com> wrote:

Leave it in!

It's a great little tool. I don't use it very often, but when I do
it is because I've decided that in the context of that piece of code it
does exactly what I want it to do with the maximum amount of clarity.

If you don't like it, then don't use it, but I can't see how it
detracts from the language at all.

The *only* argument that I have heard for removing it is that some
people don't immediately intuit how to use it. I didn't have any trouble
with it at all. It follows one of the most basic programming patterns ever:
"For all x in X, if predicate P is true, do something." The use of the
keyword "where" makes perfect sense in that context, and when I read it out
loud, it sounds natural: "For all x in X where P, do something." That is an
elegant, succinct, and clear way of stating exactly what I want my program
to do.

I don't doubt that it has caused some confusion for some people,
but I'm not sold that that is a good enough reason to get rid of it. It
seems strange to get rid of a tool because not everyone understands how to
use it immediately, without ever having to ask a single question. As long
as its not a dangerous tool (and it isn't), then keep it in the workshop
for those times when it comes in handy. And even if there is some initial
confusion, it doesn't sound like it lasted that long. It's more like, "Does
this work like X, or does this work like Y? Let's see...oh, it works like
X. Ok." That's the entire learning curve...about 5 seconds of curiosity
followed by the blissful feeling of resolution.

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

On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>>>>>>> swift-evolution@swift.org> wrote:

> And to follow-up to myself once again, I went to my "Cool 3rd

Party Swift Repos" folder and did the same search. Among the 15 repos in
that folder, a joint search returned about 650 hits on for-in (again with
some false positives) and not a single for-in-while use.

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

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

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

That is worrying if true, because it suggests that it's enabling
'dialects' of Swift, an explicit anti-goal of the language.

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

l8r
Sean

_______________________________________________

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

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

_______________________________________________

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

[let_var_go]

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 <letvargo@gmail.com> 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 <xiaodi.wu@gmail.com> 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 <letvargo@gmail.com> 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 <xiaodi.wu@gmail.com> wrote:

On Mon, Jun 13, 2016 at 10:44 AM, let var go <letvargo@gmail.com> >>>> 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 <xiaodi.wu@gmail.com> wrote:

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

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

--1

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

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

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

I think this idea--if you don't like it, then you don't have to use
it--is indicative of a key worry here: it's inessential to the language and
promotes dialects wherein certain people use it and others wherein they
don't. This is an anti-goal.

On Fri, Jun 10, 2016 at 12:10 let var go <letvargo@gmail.com> wrote:

Leave it in!

It's a great little tool. I don't use it very often, but when I do
it is because I've decided that in the context of that piece of code it
does exactly what I want it to do with the maximum amount of clarity.

If you don't like it, then don't use it, but I can't see how it
detracts from the language at all.

The *only* argument that I have heard for removing it is that some
people don't immediately intuit how to use it. I didn't have any trouble
with it at all. It follows one of the most basic programming patterns ever:
"For all x in X, if predicate P is true, do something." The use of the
keyword "where" makes perfect sense in that context, and when I read it out
loud, it sounds natural: "For all x in X where P, do something." That is an
elegant, succinct, and clear way of stating exactly what I want my program
to do.

I don't doubt that it has caused some confusion for some people,
but I'm not sold that that is a good enough reason to get rid of it. It
seems strange to get rid of a tool because not everyone understands how to
use it immediately, without ever having to ask a single question. As long
as its not a dangerous tool (and it isn't), then keep it in the workshop
for those times when it comes in handy. And even if there is some initial
confusion, it doesn't sound like it lasted that long. It's more like, "Does
this work like X, or does this work like Y? Let's see...oh, it works like
X. Ok." That's the entire learning curve...about 5 seconds of curiosity
followed by the blissful feeling of resolution.

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

On Fri, Jun 10, 2016 at 11:23 AM, Sean Heber via swift-evolution < >>>>>>>>> swift-evolution@swift.org> wrote:

> And to follow-up to myself once again, I went to my "Cool 3rd

Party Swift Repos" folder and did the same search. Among the 15 repos in
that folder, a joint search returned about 650 hits on for-in (again with
some false positives) and not a single for-in-while use.

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

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

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

That is worrying if true, because it suggests that it's enabling
'dialects' of Swift, an explicit anti-goal of the language.

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

l8r
Sean

_______________________________________________

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

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

_______________________________________________

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