-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.
* 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.
I didnāt even know while loops supported āwhereā. I canāt even imagine
what that would look like, or how I would reason about one if I saw one. I
Googled around a little bit and couldnāt find any examples. If they exist,
sure, go ahead, get rid of them. Nobody will miss them.
Actually, we had a *huge* chain where there were definitely people who said
they would miss them, even though as you said it appears scarcely used and
not very well known. The pernicious problem with it was that it forced even
unrelated boolean assertions to be chained with `where`, as in:
while let x = iterator.next() where y < z { ... }
It definitely makes sense on āforā, though. Lots and lots of people will
miss that; itās a pretty well-known feature.
(See Erica's statistics below.)
Also, after everything you said, itās still not unintuitive. That is not
how languages work at all. Languages spoken by human beings are always
ambiguous to some extent, and we use context to determine which meaning is
correct:
(Quote from
Announcing SyntaxNet: The Worldās Most Accurate Parser Goes Open Source ā Google Research Blog
)
One of the main problems that makes parsing so challenging is that human
languages show remarkable levels of ambiguity. It is not uncommon for
moderate length sentences - say 20 or 30 words in length - to have
hundreds, thousands, or even tens of thousands of possible
syntactic structures. A natural language parser must somehow search through
all of these alternatives, and find the most plausible structure given
the context. As a very simple example, the sentence "Alice drove down the
street in her car" has at least two possible dependency parses:
The first corresponds to the (correct) interpretation where Alice is
driving in her car; the second corresponds to the (absurd, but
possible) interpretation where the street is located in her car. The
ambiguity arises because the preposition āin" can either
modify drove or street; this example is an instance of what is
called prepositional phrase attachment ambiguity.
Even algebra is not completely unambiguous - you need to use BODMAS rules
to disambiguate potential meanings.
Itās this context which I think youāre missing when zooming in at the word
āwhereā:
- The context that this is a variation of a āfor x in yā loop. We know
that it loops through every item in āy' and assigns it āxā. It is literally
Section 2 of the 'Swift Tour' - you learn how to assign a variable, and
then you learn about the āfor x in yā loop. Everybody should recognise it.
- The context that āxā is the subject, so āwhereā is clearly a condition
for x to fulfill
- The context that āwhereā occurs after āinā, so it follows the order in
which its written: āfor every x in y, where such-and-such is true, do ā¦ā
- The āfor x in yā loop is a data-driven loop. It doesnāt even have a loop
index. It is not like a C for loop and you shouldnāt expect to reason about
it that way.
* There are other ways to break from a loop or continue to the next
iteration without performance penalty. Nearly all of these serve more
general purposes than a `where` clause. Some of these (such as `if` or
`guard`) would already be familiar to a new user before they encounter
loops, assuming a typical order for learning a programming language. Many
of these (such as filtering methods on collections, or simply `if`) would
be familiar to a user of another C-family language. Therefore, the `where`
clause provides no independent utility, is not more discoverable than its
alternatives, and is not required for progressive disclosure of an
important facility to a learner (i.e. a simplified syntax for those who may
not be ready for the advanced concepts needed to use a more fully-featured
alternative).
You say the points in favour of removal are not handwavey, but Iām still
not convinced. āThere are other ways to go to where this shortcut goesā is
not reasoning. And Iād definitely argue that it is more discoverable than
the āguardā statement. The guard statement is stone-dead last at the end of
a massive āControl-Flowā page. I would guess that most first-time readers
skip those topics for later.
You cannot say the same about `if`.
The point here is that this is not a slippery slope. If `where` offered
independent utility, then some confusion alone probably wouldn't be enough
to justify removal, though it may justify some consideration for change.
However, as the extensive discussion has shown, there is nothing `where`
can do that something else can't do better. I know you like it for style,
but that's not sufficient grounds for keeping something confusing, IMO.
Itās more readable. It does that better.
Earlier in this thread and others, I gave my reasoning where I disagree
with this assertion about being more readable.
The tests also seem to show that (bizarrely) itās also slightly faster
than the alternatives.
I don't believe there has been any demonstration that it's faster than
`guard` or `if`. I would be shocked if that were the case.
Ā·Ā·Ā·
On Fri, Jun 10, 2016 at 6:10 AM, Karl <razielim@gmail.com> wrote:
Karl
On 10 Jun 2016, at 08:25, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
On Fri, Jun 10, 2016 at 12:48 AM, Brandon Knope <bknope@me.com> wrote:
On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote:
On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:
Le 9 juin 2016 Ć 14:55, Xiaodi Wu via swift-evolution < >>> swift-evolution@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."
Couldn't we find examples of anyone being confused at any syntax?
Especially with an unfamiliar construct in a new language.
If people find the new proposed syntax confusing, do we pull that too? At
what point do we stop?
That is why I favored (1) removal of the confusing syntax altogether; and
(2) this proposal, which involves aligning the confusing syntax with an
existing syntax. In short, no new syntax to get confused about.
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.
I still have yet to see widespread confusion of this. A few people
learning swift here or there, but once they learn the syntax...do they
still find it confusing?
I expect some concrete data on stuff like this...especially with proposed
syntax changes.
Without concrete examples, what would stop one from coming in here and
waving their hands around to push *what they like* through?
Here's what's not handwavy:
Conclusion: the `where` clause is unprecedented, unintuitive, provides no
independent utility, is not more discoverable than alternatives, and is not
required for pedagogical reasons; however, it has been used incorrectly by
at least some users. Therefore, it is harmful and ought to be removed or
reformed.
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.
Again, where is this significant proportion of users? I don't mean to
hound you on this, but I am genuinely curious where this is all coming from.
We were talking about the hypothetical something here and what the bar
should be for removal from the language. My response is that being
confusing at first sight *is* a legitimate consideration for removal from
the language. If something turns out to be a confusing way to describe a
straightforward concept, then the more widespread the confusion, the more
urgent its removal.
The burden of evidence is on the proposers of these ideas.
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.
What is clear to one person may be confusing to another. There is no
perfect syntax that will not make it confusing for some users.
----
I really think it is important to come armed with more information with
these proposals. It's easy to say a significant proportion of people are
confused but it would make me much more comfortable to see this data to
back it up.
What if we are spinning our wheels for no reason on a feature that *most*
don't find confusing? What if we make a bigger proportion of those who did
understand it more confused now?
Brandon
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@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@swift.org> wrote:
>
>
>> On Jun 9, 2016, at 11:11 AM, Charlie Monroe < >>>> charlie@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution