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*…). 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.
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.
Karl
> On 10 Jun 2016, at 17:24, Erica Sadun via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Jun 10, 2016, at 9:22 AM, Erica Sadun via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On Jun 10, 2016, at 8:02 AM, Xiaodi Wu via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> On Fri, Jun 10, 2016 at 7:18 AM, Haravikk <[email protected]
>>> <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
