[swift-evolution] Review on SE-0007 (Remove C-style for-loops with conditions and incrementers)

[Michael Henson]

Evaluation of the Proposal:

I agree, with caveats.

Is the problem significant enough to warrant a language change:
(and)
Does this proposal fit well:

Yes, given both the Swift goal of removing or reducing the opportunity for
programmer errors and the inclusion of Sequence and Generator as standard
language concepts.

How does the proposal compare to other languages or libraries:

I'm coming from a background of 20+ years writing in C-like languages. I've
only worked with Swift significantly since the release of Xcode 7.0, and
feel competent but not fluent in it so far.

My first reaction to the proposal was that I had a trivial counterexample.
Without C-like for loops, how would one do this?

for var i = 0; i < collection.count; i += 2 {
   doAThing(collection[i])
}

All of the documentation I've read so far (I double-checked) considers only
*consecutive* iteration over collections. The possibility of more advanced
iterations is only referred to briefly at the end of the Collection Types
section of The Swift Programming Language with a simple mention of the
.generate() method.

Even after reading the early discussions of this proposal in which .indices
and .stride(...) were mentioned, and thus having something specific to look
for, it took some work to find either of them in the Standard Library
reference.

If the expectation is that "people new to programming" should be able to
pick up this idea, I think the concepts behind Sequences, Generators, and
non-consecutive iteration will have to be given first-class status in the
language documentation.

Also, as an aside, off-by-one errors are still easy to get with a poor
choice of range operator. It might be more-or-less trivial to add a
compiler warning if it sees the "..." operator in the 'in' clause of a
for-in construct versus trying to design the possibility out altogether.

How much effort did you put into the review:

I spent a good bit of this evening reading through the documentation and
these discussions. I worked through the idea of getting rid of all
'for'-like constructs in favor of Generator/.forEach() based alternatives
until break/continue semantics under for-in and their absence under
Generator.forEach() came up in the thread. Then I settled on the need to
shift the educational materials along with removing the old construct.

Mike Henson
mikehenson at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151209/bed4b822/attachment.html>