[Proposal] Add keyword "by" as syntactic sugar to streamline For-In-loop


(Ted van Gaalen) #1

Hi Vladimir,

In the past weeks, I wrote extensively on swift-evolution
about an alternative for the classical for-loop.
So extensively that it irritated the ”Collectians”
who (indirectly) classified me and some similar others
as “Forloopians” and also “Traditionalists”…
I consider this as a great honor. :o)

Anyway, among other alternatives, I wrote this on April 5th.2016:

So, to me the best option is still to bring the for ;; back
or to make a new Swift equivalent for it as described here again.

for d from 10.0 to 5.0 by -0.1 tolerance 0.01 //tolerance is optional
{
    print(d)
}

     for v from v1 to v2 by vstep // it can’t be any simpler than this.

Of course, working with ALL existing numerical types, Int, Float, Double..
( Btw. me wishing: consolidate all floating point types into just one type, preferably Double!)

Apart from the “tolerance” option, which I intended for float boundaries in for-loops,
this is not my really original idea, because the traditional for-loop exist
more or less like this in most program languages for decades.

What do you think about my suggested for-loop?

I don’t like this variant at all:

for i in (1...10).striding(by: 3) {..}
for i in (1...10).striding(by: -3) {..}

It is downright ugly, cumbersome to write,
hard to read and also functionally very limited: **
- ranges like (10…-5) are not allowed
- ranges / for..in.. with other numerical types like Float and Double are not possible!
- I am still doubtful about optimization:
         the compiler always has to look what is behind the “in”

Ergo: There is still no good alternative for the classical for ;; that was in Swift.

One has to use “while {...}” loops.
which means specifying an iteration in 3 lines more and a bigger change
for errors.

But.. compare how the next is more clear and nice looking, has less noise,
how faster this will be typed.. :

for i in 1...10 by 3 {...}
for i in 1...10 by -3 {…}

This looks better, indeed,
but still has the same severe limitations **

My opinion: this .striding is about Range type. Range type is used in many
places, not just in for-in loop. It is important to have handy and clear
methods for Range. But. If we are talking about loop - why(why?) can't we
have such a great syntax for such a common loop task?

That is my honest opinion too.

The only ambition of the for-loop I presented is for it
to be a convenience construct for the “while” loop
which it has always been. it is actually the sole
reason why it was invented in the first place.

There is nothing to be ashamed of to bring back
the for ;; . I am very serious here.

It is (was) one of the most powerful control statements in Swift!

IMHO it amazes me that people go through so much
unnecessary effort in an attempt to replace / circumvent
a nearly perfect iteration statement.

But I wrote about all this already too many times.

Please note that I do also see many good things and developments in Swift!

met vriendelijke groeten

TedvG


(Vladimir) #2

Right now it seems for me that for-in + "step" is the best solution that provides what we need with minimal changes :

for i in 0..<10 step 2 {
}

for i in 0..<10 step -2 {
}

for i in 0.1..<10.5 step 0.5 {
}

("step" is optional)

i.e. like current for-in loop, but with additional features.

···

On 14.04.2016 2:46, Ted F.A. van Gaalen wrote:

Hi Vladimir,

In the past weeks, I wrote extensively on swift-evolution
about an alternative for the classical for-loop.
So extensively that it irritated the ”Collectians”
who (indirectly) classified me and some similar others
as “Forloopians” and also “Traditionalists”…
I consider this as a great honor. :o)

Anyway, among other alternatives, I wrote this on April 5th.2016:

So, to me the best option is still to bring the for ;; back
or to make a new Swift equivalent for it as described here again.

for d from 10.0 to 5.0 by -0.1 tolerance 0.01 //tolerance is optional
{
    print(d)
}

     for v from v1 to v2 by vstep // it can’t be any simpler than this.

Of course, working with ALL existing numerical types, Int, Float, Double..
( Btw. me wishing: consolidate all floating point types into just one type,
preferably Double!)

Apart from the “tolerance” option, which I intended for float boundaries
in for-loops,
this is not my really original idea, because the traditional for-loop exist
more or less like this in most program languages for decades.

What do you think about my suggested for-loop?

I don’t like this variant at all:

for i in (1...10).striding(by: 3) {..}
for i in (1...10).striding(by: -3) {..}

It is downright ugly, cumbersome to write,
hard to read and also functionally very limited: **
- ranges like (10…-5) are not allowed
- ranges / for..in.. with other numerical types like Float and Double are
not possible!
- I am still doubtful about optimization:
         the compiler always has to look what is behind the “in”

Ergo: There is still no good alternative for the classical for ;; that was
in Swift.

One has to use “while {...}” loops.
which means specifying an iteration in 3 lines more and a bigger change
for errors.

But.. compare how the next is more clear and nice looking, has less noise,
how faster this will be typed.. :

for i in 1...10 by 3 {...}
for i in 1...10 by -3 {…}

This looks better, indeed,
but still has the same severe limitations **

My opinion: this .striding is about Range type. Range type is used in many
places, not just in for-in loop. It is important to have handy and clear
methods for Range. But. If we are talking about loop - why(why?) can't we
have such a great syntax for such a common loop task?

That is my honest opinion too.

The only ambition of the for-loop I presented is for it
to be a convenience construct for the “while” loop
which it has always been. it is actually the sole
reason why it was invented in the first place.

There is nothing to be ashamed of to bring back
the for ;; . I am very serious here.

It is (was) one of the most powerful control statements in Swift!

IMHO it amazes me that people go through so much
unnecessary effort in an attempt to replace / circumvent
a nearly perfect iteration statement.

But I wrote about all this already too many times.

Please note that I do also see many good things and developments in Swift!

met vriendelijke groeten

TedvG