• Bill Baxter (9/9) Apr 27 2008 Just started wondering why we really need the foreach keyword.
• BCS (4/20) Apr 27 2008 I think the syntax of for is already strange enough:
• Bill Baxter (17/40) Apr 27 2008 Ok, but nobody writes code like that unless they're gunning to win an
• Robert Fraser (2/4) Apr 28 2008 Infinite loop'd!
• terranium (1/10) Apr 28 2008 does D allow for(x;y)? I think it's easy to remember - if you need forea...
• terranium (1/3) Apr 28 2008 If you're looking to get rid of keywords, get rid of goto ^-^
• Robert Fraser (3/18) Apr 28 2008 Java's solution is to use a colon in place of the semicolon.
• Nick Sabalausky (21/23) May 06 2008 I rather like C#'s "x in y". It's more obvious than either the differenc...
• downs (5/5) Apr 28 2008 Note that if we had trailing delegate syntax, combined with a break/cont...
• BCS (2/11) Apr 28 2008 assert is removed completely on release. as a function that won't happen...
• downs (4/21) Apr 28 2008 Replace it with an empty body and make the parameters lazy.
• Koroskin Denis (4/14) Apr 28 2008 Remove assert and you loose static assert, too.
• downs (3/23) Apr 28 2008 This is easy to solve in concept, although possibly hard in actual imple...

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

BCS <ao pathlink.com> writes:

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();

Bill Baxter <dnewsgroup billbaxter.com> writes:

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

Robert Fraser <fraserofthenight gmail.com> writes:

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

Infinite loop'd!

terranium <spam here.lot> writes:

 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.

terranium <spam here.lot> writes:

 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 ^-^

Robert Fraser <fraserofthenight gmail.com> writes:

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)

"Nick Sabalausky" <a a.a> writes:

"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:fv48l1$670$4 digitalmars.com...
 Java's solution is to use a colon in place of the semicolon.

 for(x : y)


between two or three semicolons, or the difference between semicolon and 

"for(x in y)". But in any language, I do think I'd prefer the dichotomy of 
"for(;;)" and "for(x in y)", as opposed to pretty much any other syntax. 
Especially for reverse iteration - "foreach_reverse" is incredibly long. So 
"for_reverse" would be an improvement. But in D's case, I don't know if 
using "in" in this manner could cause parsing trouble since "in" already has 
another meaning.

Assuming it's reasonably possible, I would vote for adding something like 
"for(x in y)" or "for(x from y)" or "for(x of y)", etc., as either a 
replacement or an alternative for "foreach(;)".

Speaking of "in", (and getting a bit off topic, sorry), I might as well put 

"ref" and "out" to be explicitly specified when calling a function:

void Foo(out int someVal) { someVal = 5; }

int bar;
Foo(out bar); // OK
Foo(bar); // Error, caller MUST show that they KNOW that bar may change

downs <default_357-line yahoo.de> writes:

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

BCS <BCS pathlink.com> writes:

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.

downs <default_357-line yahoo.de> writes:

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

"Koroskin Denis" <2korden gmail.com> writes:

On Mon, 28 Apr 2008 16:29:11 +0400, downs <default_357-line yahoo.de>  
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

Remove assert and you loose static assert, too.
Unless, you introduce static_assert keyword :)

downs <default_357-line yahoo.de> writes:

Koroskin Denis wrote:
 On Mon, 28 Apr 2008 16:29:11 +0400, downs <default_357-line yahoo.de>
 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

 
 Remove assert and you loose static assert, too.
 Unless, you introduce static_assert keyword :)

This is easy to solve in concept, although possibly hard in actual
implementation.

Implement CTFE exceptions :)