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

Sat Jun 11 14:50:16 CDT 2016

On Sat, Jun 11, 2016 at 2:42 PM, Thorsten Seitz <tseitz42 at icloud.com> wrote:

>
>
> Am 10.06.2016 um 07:08 schrieb Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org>:
>
> On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls at icloud.com> wrote:
>
>>
>> Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> a écrit :
>>
>> There have been, in previous threads, several examples given where users
>> of Swift have found the behavior of `where` to be misleading and confusing.
>>
>>
>> Sorry Xiaodi, but beside you (on multiple instances), and recently Erica,
>> I have do not recall hearing that many voices saying that 'where' is
>> confusing.
>>
>
> Shawn Erickson wrote this to the list just yesterday:
>
> "I support your position on the use of where and while/when being
> confusing in the loop statement. I (and I know others) have for example
> used where in a loop statement mistakenly thinking it would terminate the
> loop early but of course learned that it basically filters what causes the
> loop body to be executed. After the fact that made sense to me but it
> didn't click at first."
>
>
>> Yes, there's was maybe even less voices stating that it is not confusing,
>> but which group is more vocal?
>>
>> Maybe I have been recently corrupt by Solid SQL queries:
>> select * from PEOPLE_TABLE where AGE_FIELD = 100
>>
>> Or by my (likely) broken English:
>> The places where I had the most fun
>>
>> But, to me, where can only suggest some filtering (thus tag to a for ..
>>  in .., continue if not matching).
>>
>
> I'm glad that you find it very clear. I do as well. That does not mean it
> is clear to everyone.
>
>
> So all these people never had contact with SQL?
>

What do you mean by this comment? Do you expect users of Swift to arrive at
the language already knowing SQL?

>
> -Thorsten
>
>
>
>
>> I know there's a linguist on the list, maybe he could comment on whether
>> or not using 'where' as a filter is proper or an abomination.
>>
>> I do not think that because something is confusing to some, or at first,
>> that it warrant removal from the language.
>>
>
> It is a very bad sign if something is confusing at first, especially to a
> significant proportion of users. It's true by definition that once you have
> mastered something you are no longer confused by it.
>
> As has been stated on this list, education is a valid and important
> consideration for Swift. If something is confusing rather than difficult
> (and the *concept* of filtering a list is not at all a difficult concept),
> and if the same underlying concept can already be invoked in alternative
> and equivalent ways that are not confusing, then it's a no-brainer that the
> confusing thing is harmful to the language and should be removed on that
> basis alone.
>
> By analogy, Chinese and Japanese share difficult writing systems. Yet many
> people use those languages daily without difficulty. Does that mean there's
> not a problem? Far from it: in fact, you'll find that many intelligent
> people have devoted their life's work to mitigating the issue. Both Chinese
> and Japanese underwent a round of simplification in the 20th century. Think
> about it: real languages used for daily life by a significant fraction of
> the world's population were revamped for the purpose of increasing
> accessibility to new learners.
>
> The by-value/by-reference is well define, but can be confusing at first.
>> Same goes for eager/lazy processing, or escaping vs non-escaping closure,
>> or even the difference between closure and function. But no one suggest to
>> remove them.
>>
>
> Value types vs. reference types is a concept (and a moderately advanced
> one), eager vs. lazy processing is a concept (and a moderately advanced
> one), and closures are a concept (and definitely an advanced one).
>
> Filtering a collection is a concept as well, and no one is suggesting its
> removal. We are proposing to simplify and rationalize the syntax by which
> filtering is invoked. If there were a way to dramatically simplify the
> syntax surrounding value types and reference types so as to diminish
> confusion, you can absolutely guarantee that there would be proposals to
> change the syntax. If I could think of one tomorrow, you'd see a thread
> tomorrow about it. I don't think I'm that smart though.
>
>
>> Dany
>>
>> In fact, the first of these proposals began with a question: how does one
>> write arbitrary Boolean assertions after a let binding? The answer (use
>> `where`) was found to be misleading and confusing.
>>
>> I think you're being unfair to say that these proposals have no purpose
>> other than an academic consistency.
>> On Thu, Jun 9, 2016 at 13:29 Jon Shier via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>         As time goes on, I’m feeling more and more that these
>>> consistency proposals are sorely misguided. Frankly, unless the syntax is
>>> confusing or misleading, even once the developer has learned the guiding
>>> principles of Swift, consistency is not a good argument for change. This
>>> proposal is the perfect example of this. No one will find the use of
>>> “where” in loops confusing, aside from those who will wonder why it was
>>> removed from if statements. There is no misleading behavior or confusing
>>> syntax here. This is just consistency for consistency’s sake. Once this
>>> proposal is done, then another will be made to remove “where” from another
>>> place in the language. Then another and another until it’s gone completely
>>> and a very useful part of the language is removed in the name of
>>> consistency. Which really just comes down to “where” isn’t used here, so it
>>> can’t be used there anymore. It’s death by a thousand cuts.
>>>
>>>
>>>
>>> Jon Shier
>>>
>>>
>>> > On Jun 9, 2016, at 1:16 PM, Erica Sadun via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>> >
>>> >
>>> >> On Jun 9, 2016, at 11:11 AM, Charlie Monroe <
>>> charlie at charliemonroe.net> wrote:
>>> >> See my latest post - included results with -Ofast. But still, using
>>> filter and lazy.filter is 10+% slower, which were the suggested
>>> alternatives to `where`.
>>> >>
>>> >>
>>> >
>>> > I need to correct this misapprehension.
>>> > My suggested alternative to where was and remains `guard`.
>>> >
>>> > -- 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
>>>
>> _______________________________________________
>> 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/15d0c8aa/attachment.html>