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

[Xiaodi Wu]

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

>
>
> Am 11.06.2016 um 22:29 schrieb L. Mihalkovic <laurent.mihalkovic at gmail.com
> >:
>
>
>
> On Jun 11, 2016, at 9:53 PM, Thorsten Seitz via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
>
> Am 10.06.2016 um 18:28 schrieb Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org>:
>
> On Fri, Jun 10, 2016 at 6:10 AM, Karl <razielim at gmail.com> wrote:
>
>> -1
>>
>> * Swift is explicitly a C-family language. In most or all other C-family
>> languages, for loop statements allow specification of conditions for
>> exiting the loop but not for filtering. Therefore, Swift's use of `where`
>> is unprecedented and needs to be learned anew by every user of Swift.
>>
>>
>> When was this decided? I distinctly remember some bloke under Craig
>> Federighi’s hair saying that it was time to “move beyond” C and essentially
>> ditch legacy conventions which no longer make sense.
>>
>
> I think you misunderstood my argument here. I don't mean that we should
> yoke ourselves to C conventions, and we should absolutely ditch C
> convention when it doesn't make sense. The big-picture argument here is
> that `where` doesn't pass the bar of correcting a C convention that no
> longer makes sense.
>
> FWIW, on the topic of syntax choices, here is what Chris Lattner had to
> say on this list:
>
> Kevin got it exa*c*tly right, but I’d expand that last bit a bit to:
>> “… pi*c*king the one that is most familiar to programmers in the
>> extended *C* *family* is a good idea.["]
>> The extended *C* *family* of language (whi*c*h in*c*ludes *C*, *C*++, Obj
>> *C*, but also *C*#, Java, Javas*c*ript, and more) is
>> an extremely popular and widely used set of languages that have a lot of
>> surfa*c*e-level similarity. I
>> don’t *c*laim to know the design rationale of all of these languages,
>> but I surmise that this is not an
>> a*c**c*ident: programmers move around and work in different languages,
>> and this allows a non-expert in the
>> language to understand what is going on. While there are things about *C*
>> that are really unfortunate IMO
>> (e.g. the de*c*larator/de*c*laration spe*c*ifier part of the grammar)
>> there is a lot of goodness in the basi
>> *c*operator set, fo*c*us on dot syntax, and more.
>> I do agree that there are some benefits to dit*c*hing bra*c*es and
>> relying on indentation instead, but there are
>> also downsides. Deviating from the *C* *family* in this respe*c*t would
>> have to provide **overwhelmingly** large
>> advantages for us to take su*c*h a plunge, and they simply don’t exist.
>
>
>
>> As I understand it, Swift is a new language with new conventions. It is
>> desirable to align as many of those as possible with existing conventions
>> so as to be easily learned, but if you limit Swift to other languages
>> conventions you deny it any identity. Did Python ask anybody’s opinion
>> before dropping curly-braces? Did people learn whatever Perl is supposed to
>> be? Look at C’s hieroglyphic for loops!
>>
>
> I don't think we disagree here.
>
>
>>
>> Realistically, “for … in … while” is not going to cause incredible
>> confusion. Removing it would cause a lot of frustration. You can’t on the
>> one hand say our users are comfortable with the axioms of C’s hieroglyphic
>> loops, and on the other hand say “for x in y while" is confusing.
>>
>> Again, as I said, once you've mastered something, by definition you find
>> it not confusing. Why should we doom x% of new users to writing a loop
>> incorrectly at least once when we don't have to?
>>
>>
>> Ah, but if you’re not “doomed” to failing once, how will you ever master
>> anything? Nobody knew how to write a C for-loop until someone showed them
>> (and even then…). Nobody is going to just open a REPL and start writing
>> code, with zero prior understanding of what Swift syntax looks like.
>>
>
> The thought here is along the lines of what Chris said, quoted above, and
> repeated here: "The extended C family of language [...] is an extremely
> popular and widely used set[;] programmers move around and work in
> different languages, and [aligning to expectations arising from other C
> family languages] allows a non-expert in the language to understand what is
> going on." By contrast, the `where` clause violates that expectation and I
> do not see "overwhelmingly large advantages" for doing so.
>
>
> What about C#'s `where` then? As C# is a member of the C family languages
> `where` is not violating expectations!
>
>
> Where is not exactly a part of c# it belongs to linq
>
>
> And that is not a part of C#??
>

SQL is a domain-specific language, and LINQ is an internal domain-specific
language with a language extension for C#. Neither is a general purpose
language.

Your example actually goes to one of Laurent's points. Should the Swift
core team or an enterprising community member propose a set of similarly
powerful tools, along with a set of language extensions that add syntactic
sugar for them, I (and I think Laurent, if I understand him correctly)
would absolutely be in favor of such an addition. But as it is, `where` is
an odd duckling. Just as you say, it looks like a component of a query
language, but it does no such thing. In a for loop, it does some filtering,
but until recently it functioned like a comma in `while` loops. Look at
those other keywords which make this sugar possible in C#: in your example,
`from` and `select`. We don't have any of that intrastructure in Swift.


> The following is an example from MSDN with `where` clearly beaing a
> keyword:
>
> *var* numQuery =
>             *from* num *in* numbers
>             *where* (num % 2) == 0
>             *select* num;
>
>
> -Thorsten
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160611/989f90c0/attachment.html>