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
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
↑ ↓← → 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
↑ ↓ ← → 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();
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.
Apr 28 2008
↑↓←→ 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)
"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
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
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.
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
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 :)
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 :)
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next