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

[L. Mihalkovic]

> On Jun 11, 2016, at 5:49 AM, Karl via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I’m sorry, but those statistics are not useful. The Swift standard library is not representative of real-world Swift code, or what Swift developers expect or appreciate about the language. You also need to consider that lots of people are reluctant to support new syntax for fear that it might as soon disappear with the next drop (*uhum*…). 

Now, IMHO this should never be an argument when dealing with Apple.. anyone who's been around long enough will tell you that nothing is safe!!! The company's entire software culture is based on this kind of musical chairs approach: when the music stops (every year at WWDC) devs are left to figure out what has become what and how much they have to change in their code. This is a bit steeper with swift because there is no 'deprecation' period... it is just gone! but they assist with the language modernization rools in xcode.


> Gathering useful statistics about the popularity of features in the Swift language is more involved than simply grep-ing the standard library.
> 
> I know for a fact that it’s not representative of the code I’ve seen, or that I see people write, and it’s not reflective of that small amount of joy they feel when they realise basic, mundane stuff like this just works and stays readable. They’ve lived with C-loops and continues, Python list contractions and the like, and this is just better. Somebody mentioned LINQ - that’s another sad story; It’s hard to reason about the performance characteristics of your code, and tiny, non-functional changes can have drastic impacts on performance. Making collections of data easy to filter is something a 21st-century programming language needs to do, and we could get things a whole lot “wronger” than a simple boolean predicate attached to “for" loops.

I mentioned LINQ.. looking at "oh dread 10% worse perf on an empty loop done 4_000_000 time is IMO bloody ridiculous (don't get me wrong, perf matters.. I come from low latency trading systems). In time, more aggressive inlining heuristics will exist, and it is the job of a good compiler to to generate the right code from a simple closure syntax.

> 
> 
> There is something (which may have gotten lost in my mail): the “for _ in  _” loop is a data-driven loop. It’s unique compared to other loops such as “while” or “repeat/while”, which simply check a Bool condition. You don’t even have a loop counter, because your place in the list doesn’t matter - it’s about iterating over a collection of individual things. With that context, having the ability to filter inline is sort-of imperative. I think its existence is entirely justified.
> 
> I would be more interested in discussing how exactly we could make it clearer than if it should exist at all. Personally, I have no attachment to the “where” keyword (I mean, I got it wrong practically every time in my mail, calling it “while”). But I’ve thought about alternatives and renaming (possible replace it with just “if”? as in “for number in 0..<10 if number% 2 == 0 { print(“\(number) is an even number") }” ). I’m not sure I can think of something that’s clearly much better than what we have now.

I am of the same opinion, if taking it out is somewhat of a blind ego trip from a small crowd looking at 3 lines in the grammar (this is a charicature, fortunately we are not there), then ... nothing to do about it (other than back to xamarin). If this is part of a larger calculated plan to do better flexibility, expressiveness, at a reasonable perf cost, then go for it. Chris Latner and team have demonstrated their planning capability with LLVM, I fully trust they are the right kind of enlighted-dictator to make Swift great.

> 
> Karl
> 
>>> On 10 Jun 2016, at 17:24, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>>> On Jun 10, 2016, at 9:22 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>> On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> On Fri, Jun 10, 2016 at 7:18 AM, Haravikk <swift-evolution at haravikk.me> wrote:
>>>>>> * The word "where" does not consistently imply `break` or `continue`. In current Swift, `where` implies `break` in the context of a `while` loop and `continue` in the context of a `for` loop. Some users intuitively guess the correct meaning in each context, while others guess the wrong meaning. Therefore, the only way to learn for sure what `where` means in any context is to read the rulebook. That, by definition, means that this is unintuitive.
>>>>> 
>>>>> This is an argument for renaming the where keyword on for loops to be more clear, or to somehow integrate continue/break to be more explicit about what the developer intends for it to do.
>>>> 
>>>> Sure: I conclude that the keyword should be *either* removed *or* reformed; both outcomes could address the issue.
>>> 
>>> This is my stance as well and I reserve the right to flit between both choices until we've fully talked it through.
>>> 
>>> One more data point. 
>>> 
>>> In the standard library there are just under 950 uses of "for in loops". There are 3 uses of "for in while" :
>>> 
>>> private/StdlibUnittest/StdlibUnittest.swift.gyb:    for j in instances.indices where i != j {
>>> public/core/Algorithm.swift:  for value in rest where value < minValue {
>>> public/core/Algorithm.swift:  for value in rest where value >= maxValue {
>>> 
>>> -- Erica
>> 
>> Actually a slight correction to that. I forgot to add the space after "in" on the first search. It's just over 600 and 3. Among the 600 are a few false positives but not many.
>> 
>> -- E
>> 
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160611/1f409040/attachment.html>