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