Thread overview
A suggestion on keyword for_each
Aug 09, 2013
SteveGuo
Aug 09, 2013
Tobias Pankrath
Aug 10, 2013
Dicebot
Aug 10, 2013
monarch_dodra
Aug 10, 2013
Andrej Mitrovic
Aug 10, 2013
Jonathan M Davis
August 09, 2013
I suggest that change keyword *for_each* to *for* since *for* is clear enough and
less letters, like C++11 does.
August 09, 2013
On Friday, 9 August 2013 at 03:30:16 UTC, SteveGuo wrote:
> I suggest that change keyword *for_each* to *for* since *for* is clear enough and
> less letters, like C++11 does.

Decent suggestion, but I don't think Walter, Andrei or any of the committers want to break everyone's code just to shorten some syntax.

As a proposal, however, it's not bad, and like you say it exists in other languages:

    // Go
    for key, val := range x {} // where x is an array, slice or map
    // Java
    for (int x in y) {}
    // C++11
    for (int &x : y) {}
    // Python (or use iter(), range(), xrange(), etc)
    for x in y: pass

Which are similar to D's foreach:

    foreach (key, value; x) {} // where x is a suitable range

I agree that the following would be unambiguous (whichever syntax we decide is better):

    for (key, value; x) {}
    for (key, value : x) {}

But it doesn't offer enough benefit to make a breaking change or introduce redundant syntax. Saving 4 chararters isn't enough justification.

Also, I don't particularly like for_reverse, since you can't use a traditional for-loop syntax with for_reverse:

    // would be syntax error
    for_reverse (i = 0; i < 5; i++) {}
    // but this works just fine
    foreach_reverse(i; 0 .. 5);

And D doesn't stand alone in the 'foreach' arena:

    // C#
    foreach(int x in y) {}
    // Perl
    foreach (@arr) {
        print $_;
    }
    // PHP
    foreach($set as $value) {}
    foreach ($set as $key => $value) {}
    // Scala
    some_items foreach println

I don't really see a compelling reason to switch. Then again, this is only my opinion, so I can't speak for the community.
August 09, 2013
On Friday, 9 August 2013 at 14:51:05 UTC, Tyler Jameson Little wrote:
> Also, I don't particularly like for_reverse, since you can't use a traditional for-loop syntax with for_reverse:
>
>     // would be syntax error
>     for_reverse (i = 0; i < 5; i++) {}

What do you think would be proper semantics for this?

August 10, 2013
On Friday, 9 August 2013 at 15:20:38 UTC, Tobias Pankrath wrote:
> On Friday, 9 August 2013 at 14:51:05 UTC, Tyler Jameson Little wrote:
>> Also, I don't particularly like for_reverse, since you can't use a traditional for-loop syntax with for_reverse:
>>
>>    // would be syntax error
>>    for_reverse (i = 0; i < 5; i++) {}
>
> What do you think would be proper semantics for this?

If the expression is simple enough, it's not out of the question for a new programmer to think it will do the same thing as the for version, but backwards.

I like foreach and foreach_reverse, because all uses of foreach can be foreach_reverse'd (except maybe some ranges), but the same does not apply in for. It lacks symmetry, which kind of bothers me.

I would prefer a step operator like Python's:

    int[] arr;
    // these two are equivalent
    foreach(x; arr[0 .. $ : -1]) {}
    foreach_reverse(x; arr[0 .. $]) {}

And for ranges:

    auto arr = genRange!int();
    foreach(x; arr.step(-1)) {}

Then I could grab every other one with a step of 2, every third with 3, etc. This would not require copying slices or ranges, but would be some nice syntax sugar. The index values in the foreach would be actual indexes into the slice/range.

If we got this feature, both foreach & foreach_reverse could probably be deprecated and merged into for (with no for_reverse). This is a pretty substantial change to the language though, so I doubt it will make it in.
August 10, 2013
`foreach_reverse` is a major design mistake considering the fact that it requires a very specific range type, contrary to normal range. For lot of ranges concept of iteration order is simply not defined making `foreach_reverse` useless. And in rare cases when it is needed, it can be replaced with plain `for`.

Hardly does any harm, but definitely not worth putting any efforts into it.
August 10, 2013
On Saturday, 10 August 2013 at 01:33:58 UTC, Dicebot wrote:
> `foreach_reverse` is a major design mistake considering the fact that it requires a very specific range type, contrary to normal range. For lot of ranges concept of iteration order is simply not defined making `foreach_reverse` useless. And in rare cases when it is needed, it can be replaced with plain `for`.
>
> Hardly does any harm, but definitely not worth putting any efforts into it.

foreach (foreach_reverse) work like a charm for iterating over dchars in a narrow string though.
August 10, 2013
On 8/9/13, SteveGuo <steveguo@outlook.com> wrote:
> I suggest that change keyword *for_each* to *for* since *for* is
> clear enough and
> less letters, like C++11 does.

Not gonna happen. What's this obsession with less letters? foreach is common among many modern languages anyway.
August 10, 2013
On Friday, August 09, 2013 12:43:08 Andrej Mitrovic wrote:
> On 8/9/13, SteveGuo <steveguo@outlook.com> wrote:
> > I suggest that change keyword *for_each* to *for* since *for* is
> > clear enough and
> > less letters, like C++11 does.
> 
> Not gonna happen. What's this obsession with less letters? foreach is common among many modern languages anyway.

Even if it were better to use for rather than foreach, the reality of the matter is that at this point in the game, it makes no sense to make changes like that. It would break lots of code without actually providing any more functionality or fixing any bugs or design flaws in the language.

Now, on top of that, you _couldn't_ use for in place of foreach thanks to how crazy versatile D's for loops are (you can put pretty much _anything_ in front of the first semicolon - including blocks of code with other for loops). Without foreach, there's no way for the compiler to distintguish between when you want foreach and when you want a normal for loop. C++ can get away with it because its for loops aren't as fancy.

- Jonathan M Davis