Just started wondering why we really need the foreach keyword.

These two

for( x ; y ; z )

for( x ; y )

do no seem to be ambiguous to me.  You do need some lookahead, but I think D has some constructs like that already.

If we're looking to get rid of keywords it seems like a candidate.  I already mistakenly type "for" when I mean "foreach" fairly often.

--bb

Reply to Bill,

> Just started wondering why we really need the foreach keyword.
> 
> These two
> 
> for( x ; y ; z )
> 
> for( x ; y )
> 
> do no seem to be ambiguous to me.  You do need some lookahead, but I
> think D has some constructs like that already.
> 
> If we're looking to get rid of keywords it seems like a candidate.  I
> already mistakenly type "for" when I mean "foreach" fairly often.
> 
> --bb
> 

I think the syntax of for is already strange enough:

int i=0;
for(for(int j=0; j<10; i+=(j++)) if (i<0) break; i; i--) somthing();

BCS wrote:
> Reply to Bill,
> 
>> Just started wondering why we really need the foreach keyword.
>>
>> These two
>>
>> for( x ; y ; z )
>>
>> for( x ; y )
>>
>> do no seem to be ambiguous to me.  You do need some lookahead, but I
>> think D has some constructs like that already.
>>
>> If we're looking to get rid of keywords it seems like a candidate.  I
>> already mistakenly type "for" when I mean "foreach" fairly often.
>>
>> --bb
>>
> 
> I think the syntax of for is already strange enough:
> 
> int i=0;
> for(for(int j=0; j<10; i+=(j++)) if (i<0) break; i; i--) somthing();

Ok, but nobody writes code like that unless they're gunning to win an obfuscation contest.

I would be much more willing to buy a justification like it's too easy to forget a ';' in a for loop which would lead to strange compiler errors.   Or it's too hard for the programmer to see the difference between two ;'s and one.  That's kinda what I expect Walter's reason was, but I was hoping to hear if that's so from someone in the know (like Walter himself).

If we're going to have foreach expressions (as was discussed in another thread recently), and they use a keyword unlike Python's foreach expressions, I would much rather be able to say
  auto sqr = [for(x; array) x*x];
than
  auto sqr = [foreach(x; array) x*x];

Those four extra letters just seem like dead weight to me.

--bb

> Just started wondering why we really need the foreach keyword.
> 
> These two
> 
> for( x ; y ; z )
> 
> for( x ; y )
> 
> do no seem to be ambiguous to me.

does D allow for(x;y)? I think it's easy to remember - if you need foreach, use foreach, normally you sould use foreach where you can, and you will need for only for some rare advanced processing, which can't be done with foreach.

> If we're looking to get rid of keywords it seems like a candidate.  I already mistakenly type "for" when I mean "foreach" fairly often.
If you're looking to get rid of keywords, get rid of goto ^-^

BCS wrote:
> int i=0;
> for(for(int j=0; j<10; i+=(j++)) if (i<0) break; i; i--) somthing();

Infinite loop'd!

Bill Baxter wrote:
> Just started wondering why we really need the foreach keyword.
> 
> These two
> 
> for( x ; y ; z )
> 
> for( x ; y )
> 
> do no seem to be ambiguous to me.  You do need some lookahead, but I think D has some constructs like that already.
> 
> If we're looking to get rid of keywords it seems like a candidate.  I already mistakenly type "for" when I mean "foreach" fairly often.
> 
> --bb

Java's solution is to use a colon in place of the semicolon.

for(x : y)

Note that if we had trailing delegate syntax, combined with a break/continue convention like we currently have with opApply, as well as return forwarding, foreach wouldn't be necessary and could be moved to a library function :)

The result would look something like: foreach([2, 3, 4, 5]) (int x) { writefln(x); }

Probably too big a change though, sadly.

Also, let's really move assert into an object.d function. There's _no_ reason this should be a keyword.

 --downs

downs wrote:
> Note that if we had trailing delegate syntax, combined with a break/continue convention like we currently have with opApply, as well as return forwarding, foreach wouldn't be necessary and could be moved to a library function :)
> 
> The result would look something like: foreach([2, 3, 4, 5]) (int x) { writefln(x); }
> 
> Probably too big a change though, sadly.
> 
> Also, let's really move assert into an object.d function. There's _no_ reason this should be a keyword.
> 
>  --downs

assert is removed completely on release. as a function that won't happen.

BCS wrote:
> downs wrote:
>> Note that if we had trailing delegate syntax, combined with a break/continue convention like we currently have with opApply, as well as return forwarding, foreach wouldn't be necessary and could be moved to a library function :)
>>
>> The result would look something like: foreach([2, 3, 4, 5]) (int x) {
>> writefln(x); }
>>
>> Probably too big a change though, sadly.
>>
>> Also, let's really move assert into an object.d function. There's _no_ reason this should be a keyword.
>>
>>  --downs
> 
> assert is removed completely on release. as a function that won't happen.

Replace it with an empty body and make the parameters lazy.

The compiler should optimize it out if you're building with -O -inline, and what's the point of building in release but not -O?

 --downs