www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Do we need "foreach"?

reply 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
Apr 27 2008
next sibling parent reply 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();
Apr 27 2008
next sibling parent 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
Apr 27 2008
prev sibling parent 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!
Apr 28 2008
prev sibling next sibling parent 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.
Apr 28 2008
prev sibling next sibling parent 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.

Apr 28 2008
prev sibling next sibling parent reply 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)
Apr 28 2008
parent "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)

I rather like C#'s "x in y". It's more obvious than either the difference between two or three semicolons, or the difference between semicolon and normal colon. Of course, C# still uses it like "foreach(x in y)" instead of "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 it out there that I vastly prefer C#'s behavior of requiring attributes like "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
May 06 2008
prev sibling parent reply 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
Apr 28 2008
next sibling parent reply 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.
Apr 28 2008
parent 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
Apr 28 2008
prev sibling parent reply "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 :)
Apr 28 2008
parent 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 :)
Apr 28 2008