www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - foreach

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
I often find myself wanting to write this:
  foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.

You can do this:
  for(;;) {}

If 'for' lets you omit any of the loop terms, surely it makes sense
that foreach would allow you to omit the first term as well?
I see no need to declare a superfluous loop counter when it is unused.
Jun 12 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
On Thursday, 12 June 2014 at 15:00:20 UTC, Manu via Digitalmars-d 
wrote:
 I often find myself wanting to write this:
   foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.

 You can do this:
   for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes 
 sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is 
 unused.
It's not really a workaround, but you can do: foreach (_; 0..n) { //Do stuff } But it still declares a loop variable.
Jun 12 2014
prev sibling next sibling parent reply simendsjo <simendsjo gmail.com> writes:
On 06/12/2014 05:00 PM, Manu via Digitalmars-d wrote:
 I often find myself wanting to write this:
   foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.
 
 You can do this:
   for(;;) {}
 
 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
 
_ is an often used identifier for "i don't care" in many languages. The following works: foreach(_; 0..n)
Jun 12 2014
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 12 June 2014 at 15:09:51 UTC, simendsjo wrote:
 _ is an often used identifier for "i don't care" in many 
 languages. The
 following works:
   foreach(_; 0..n)
One issue is that "_" is still an actual identifier, with normal name collision rules. So that works only once. When you nest your loops, you'll end up having conflicts, and name your "i don't care variable" things such as "_", "__", "___", "_1", "_2" etc... It actually happens quite often I find.
Jun 12 2014
parent reply simendsjo <simendsjo gmail.com> writes:
On 06/12/2014 05:46 PM, monarch_dodra wrote:
 On Thursday, 12 June 2014 at 15:09:51 UTC, simendsjo wrote:
 _ is an often used identifier for "i don't care" in many languages. The
 following works:
   foreach(_; 0..n)
One issue is that "_" is still an actual identifier, with normal name collision rules. So that works only once. When you nest your loops, you'll end up having conflicts, and name your "i don't care variable" things such as "_", "__", "___", "_1", "_2" etc... It actually happens quite often I find.
Yeah, not good. Does any sane person use _ as a variable identifier and then reference it? A breaking change would be a special rule so _ can never be used and is allowed to shadow. Of course - this could break existing code, so it will never happen :)
Jun 12 2014
next sibling parent "Rene Zwanenburg" <renezwanenburg gmail.com> writes:
On Thursday, 12 June 2014 at 15:56:17 UTC, simendsjo wrote:
 Yeah, not good. Does any sane person use _ as a variable 
 identifier and
 then reference it? A breaking change would be a special rule so 
 _ can
 never be used and is allowed to shadow. Of course - this could 
 break
 existing code, so it will never happen :)
Even if it wouldn't break any code, special rules are bad. Enhancing foreach so the loop counter can be omitted is be better IMO. Consistent with for(;;), and avoids a special rule.
Jun 12 2014
prev sibling next sibling parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 12/06/2014 16:57, simendsjo wrote:
 On 06/12/2014 05:46 PM, monarch_dodra wrote:
 On Thursday, 12 June 2014 at 15:09:51 UTC, simendsjo wrote:
 _ is an often used identifier for "i don't care" in many languages. The
 following works:
    foreach(_; 0..n)
One issue is that "_" is still an actual identifier, with normal name collision rules. So that works only once. When you nest your loops, you'll end up having conflicts, and name your "i don't care variable" things such as "_", "__", "___", "_1", "_2" etc... It actually happens quite often I find.
Yeah, not good. Does any sane person use _ as a variable identifier and then reference it? A breaking change would be a special rule so _ can never be used and is allowed to shadow.
That might be a more flexible solution, because there is also this usage: foreach (i, _; range){...} I wonder if there may be other cases where '_' would be useful. Potentially, there's also tuple unpacking syntax: auto (v, _) = myTuple; // throw away second element
 Of course - this could break existing code, so it will never happen :)
I think we can break existing code if it's bad code. Using '_' as a variable name could be considered bad enough to disallow.
Jun 12 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Nick Treleaven:

there is also this usage:

 foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
 Potentially, there's also tuple unpacking syntax:

 auto (v, _) = myTuple;	// throw away second element
This is a very important usage. Worthing breaking D2 on. Bye, bearophile
Jun 12 2014
next sibling parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 12/06/2014 17:59, bearophile wrote:
 there is also this usage:

 foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
Perhaps with something other than a range then. There are some uses in Phobos: std/algorithm.d: foreach (i, _; args) std/exception.d: foreach (index, _; FieldTypeTuple!C) std/typecons.d: foreach (i, _; Tup1.Types) std/typecons.d: foreach (i, _; Tup1.Types) std/typecons.d: foreach (i, _; Types) // Rely on the field layout std/typecons.d: foreach (i, _; Types) std/variant.d: foreach (i, _; params)
Jun 12 2014
parent Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 12/06/2014 18:30, Nick Treleaven wrote:
 On 12/06/2014 17:59, bearophile wrote:
 there is also this usage:

 foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
Perhaps with something other than a range then. There are some uses in Phobos: std/algorithm.d: foreach (i, _; args) std/exception.d: foreach (index, _; FieldTypeTuple!C) std/typecons.d: foreach (i, _; Tup1.Types) std/typecons.d: foreach (i, _; Tup1.Types) std/typecons.d: foreach (i, _; Types) // Rely on the field layout std/typecons.d: foreach (i, _; Types) std/variant.d: foreach (i, _; params)
Because _ is not a language feature, this identifier is actually less common. The prevailing one in Phobos is: foreach (i, Unused; ...) std/algorithm.d:7 std/array.d:1 std/datetime.d:1 std/parallelism.d:2 std/range.d:28 std/typecons.d:3 This is actually used more than any uses of 'foreach (_;' (2 uses) or 'foreach (Unused;' (10 uses) in Phobos! This is true even if we treat std.range as an anomaly. (I also tried a case-insensitive search).
Jun 14 2014
prev sibling next sibling parent "JR" <zorael gmail.com> writes:
On Thursday, 12 June 2014 at 16:59:34 UTC, bearophile wrote:
 Nick Treleaven:

there is also this usage:

 foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
Would enforcing immutability there be a breaking change? foreach (/*immutable*/ i; _; range) { version(none) i = 0; }
Jun 13 2014
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/12/2014 06:59 PM, bearophile wrote:
 Nick Treleaven:

 there is also this usage:

 foreach (i, _; range){...}
I think this is a very uncommon usage. I think I have not used it so far.
Have you ever used void[0][T]?
Jun 13 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Timon Gehr:

 Have you ever used void[0][T]?
I have never used that so far. What is it useful for? Bye, bearophile
Jun 14 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/14/2014 05:33 PM, bearophile wrote:
 Timon Gehr:

 Have you ever used void[0][T]?
I have never used that so far. What is it useful for? Bye, bearophile
It's a hash set with a somewhat awkward interface.
Jun 14 2014
prev sibling next sibling parent "Demetri" <Supernova2003dh yahoo.com> writes:
On Thursday, 12 June 2014 at 15:56:17 UTC, simendsjo wrote:
 On 06/12/2014 05:46 PM, monarch_dodra wrote:
 On Thursday, 12 June 2014 at 15:09:51 UTC, simendsjo wrote:
 _ is an often used identifier for "i don't care" in many 
 languages. The
 following works:
   foreach(_; 0..n)
One issue is that "_" is still an actual identifier, with normal name collision rules. So that works only once. When you nest your loops, you'll end up having conflicts, and name your "i don't care variable" things such as "_", "__", "___", "_1", "_2" etc... It actually happens quite often I find.
Yeah, not good. Does any sane person use _ as a variable identifier and then reference it? A breaking change would be a special rule so _ can never be used and is allowed to shadow. Of course - this could break existing code, so it will never happen :)
An identifier could be chosen that started with two underscores. Those are already reserved.
Jun 12 2014
prev sibling parent reply Nick Treleaven <ntrel-public yahoo.co.uk> writes:
On 12/06/2014 16:57, simendsjo wrote:
 Does any sane person use _ as a variable identifier and
 then reference it?
I forgot that C gettext has a macro called _(), and this D version also has it (which is available via dub): https://github.com/NCrashed/dtext/blob/master/source/dtext.d#L115 string getdtext(string s, string locale = ""){...} /// Short name for getdtext alias getdtext _; ... writeln(_("Hello, world!"));
Jun 13 2014
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 13 June 2014 at 15:18:52 UTC, Nick Treleaven wrote:
 On 12/06/2014 16:57, simendsjo wrote:
 Does any sane person use _ as a variable identifier and
 then reference it?
I forgot that C gettext has a macro called _(), and this D version also has it (which is available via dub): https://github.com/NCrashed/dtext/blob/master/source/dtext.d#L115 string getdtext(string s, string locale = ""){...} /// Short name for getdtext alias getdtext _; ... writeln(_("Hello, world!"));
C++ also recently defined some std::placeholders, which are _1, _2 through _N.
Jun 13 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Manu:

 I see no need to declare a superfluous loop counter when it is 
 unused.
I agree. What's Walter opinion on this? Bye, bearophile
Jun 12 2014
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 12 June 2014 at 15:14:44 UTC, bearophile wrote:
 Manu:

 I see no need to declare a superfluous loop counter when it is 
 unused.
I agree. What's Walter opinion on this? Bye, bearophile
Enhancement request filed last year: https://issues.dlang.org/show_bug.cgi?id=9009
Jun 12 2014
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Jun 2014 11:00:11 -0400, Manu via Digitalmars-d  
<digitalmars-d puremagic.com> wrote:

 I often find myself wanting to write this:
   foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.
The compiler has to assign a variable to this somehow so it can increment and test. Naming it isn't the worst thing in the world. As others have said, pick an uncommon name.
 You can do this:
   for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
But that doesn't increment a variable and test it. If you wanted to loop for N times, you need a variable. You have to give it a name, it doesn't seem worth adding a feature to save that little bit of thinking. The thing about it is, you don't need to type more than is necessary: foreach(L1; 0..n) { foreach(L2; 0..n) { } } Doesn't seem that bad to me. -Steve
Jun 12 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jun 12, 2014 at 01:11:12PM -0400, Steven Schveighoffer via
Digitalmars-d wrote:
 On Thu, 12 Jun 2014 11:00:11 -0400, Manu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 
I often find myself wanting to write this:
  foreach(; 0..n) {}
In the case that I just want to do something n times and I don't
actually care about the loop counter, but this doesn't compile.
The compiler has to assign a variable to this somehow so it can increment and test. Naming it isn't the worst thing in the world. As others have said, pick an uncommon name.
A variable doesn't require a name, if user code never references it. All the compiler cares about is that a symbol is created for it, that can be used when generating the loop condition code. Anonymous functions don't have names either, and the compiler handles that just fine. (Well, OK, an internal unique identifier is generated for it, but that's essentially what's being asked for here by the OP.) Or, for that matter, ignored function arguments: void delegate(int) dg = (int) { // Name not needed for ignored argument here. }; --T
Jun 12 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/12/14, 2:11 PM, Steven Schveighoffer wrote:
 On Thu, 12 Jun 2014 11:00:11 -0400, Manu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 I often find myself wanting to write this:
   foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.
The compiler has to assign a variable to this somehow so it can increment and test. Naming it isn't the worst thing in the world. As others have said, pick an uncommon name.
 You can do this:
   for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
But that doesn't increment a variable and test it. If you wanted to loop for N times, you need a variable.
The compiler needs a variable. The programmer doesn't.
Jun 12 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Jun 2014 13:36:20 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:

 On 6/12/14, 2:11 PM, Steven Schveighoffer wrote:
 On Thu, 12 Jun 2014 11:00:11 -0400, Manu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 I often find myself wanting to write this:
   foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.
The compiler has to assign a variable to this somehow so it can increment and test. Naming it isn't the worst thing in the world. As others have said, pick an uncommon name.
 You can do this:
   for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
But that doesn't increment a variable and test it. If you wanted to loop for N times, you need a variable.
The compiler needs a variable. The programmer doesn't.
In response to both you and HS Teoh, so what? It's not hard to create a variable, just do it. This seems like the most insignificant time-saving feature that will really have almost no impact on anybody. It's not worth the risk it adds some bug to the compiler to add this feature. -Steve
Jun 12 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 6/12/14, 2:40 PM, Steven Schveighoffer wrote:
 On Thu, 12 Jun 2014 13:36:20 -0400, Ary Borenszweig
 <ary esperanto.org.ar> wrote:

 On 6/12/14, 2:11 PM, Steven Schveighoffer wrote:
 On Thu, 12 Jun 2014 11:00:11 -0400, Manu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 I often find myself wanting to write this:
   foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.
The compiler has to assign a variable to this somehow so it can increment and test. Naming it isn't the worst thing in the world. As others have said, pick an uncommon name.
 You can do this:
   for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
But that doesn't increment a variable and test it. If you wanted to loop for N times, you need a variable.
The compiler needs a variable. The programmer doesn't.
In response to both you and HS Teoh, so what? It's not hard to create a variable, just do it. This seems like the most insignificant time-saving feature that will really have almost no impact on anybody. It's not worth the risk it adds some bug to the compiler to add this feature. -Steve
Steven, there is not one thing that makes D great. There are many. Dissected and viewed individually most people would regard the insignificant: much like you are doing here. But the aggregated whole that is D today, is a thing of beauty. And it wouldn't be that way were it if not for these ostensibly trifling features. While I do not see this as a showstopper for anyone, including, it doesn't warrant such vehement attack. It is a convenience feature that improves the overall experience of the D programmer. A plus in my mind and worthy of the time required to discuss, agree upon a solution and implement.
Jun 12 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Jun 2014 14:55:52 -0400, Andrew Edwards <ridimz yahoo.com>  
wrote:

 On 6/12/14, 2:40 PM, Steven Schveighoffer wrote:
 On Thu, 12 Jun 2014 13:36:20 -0400, Ary Borenszweig
 <ary esperanto.org.ar> wrote:

 On 6/12/14, 2:11 PM, Steven Schveighoffer wrote:
 On Thu, 12 Jun 2014 11:00:11 -0400, Manu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 I often find myself wanting to write this:
   foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.
The compiler has to assign a variable to this somehow so it can increment and test. Naming it isn't the worst thing in the world. As others have said, pick an uncommon name.
 You can do this:
   for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is  
 unused.
But that doesn't increment a variable and test it. If you wanted to loop for N times, you need a variable.
The compiler needs a variable. The programmer doesn't.
In response to both you and HS Teoh, so what? It's not hard to create a variable, just do it. This seems like the most insignificant time-saving feature that will really have almost no impact on anybody. It's not worth the risk it adds some bug to the compiler to add this feature. -Steve
Steven, there is not one thing that makes D great. There are many. Dissected and viewed individually most people would regard the insignificant: much like you are doing here. But the aggregated whole that is D today, is a thing of beauty. And it wouldn't be that way were it if not for these ostensibly trifling features.
Sorry, saving 1-2 characters typing is really minor. This does not, in my opinion of course, have any significant improvement on usability for D. It simply does not carry it's own weight, and the potential to create bugs in the foreach handling would be not worth the risk. Typically, one uses i,j,k, etc for loops indexes. It's not so much more difficult to do foreach(i;... vs. foreach(;...
 While I do not see this as a showstopper for anyone, including, it  
 doesn't warrant such vehement attack. It is a convenience feature that  
 improves the overall experience of the D programmer. A plus in my mind  
 and worthy of the time required to discuss, agree upon a solution and  
 implement.
It's not an attack of any kind, it's just a rebuttal. It in no way reflects on the proposer or the defenders of the proposal. If there is some significant improvement to be shown, I happily would reconsider my position. Can you name a place where the improvement is more than just saving the typing of 'i', 'j', or 'k'? There are hundreds of such proposals made for D, and many of them are rejected due to the lack of improvement to the language. This is not a unique situation. The bar must be set high for new features, or we would have a mess of a language. I will note obviously that I do not have the final say anyway. It's just my opinion. -Steve
Jun 12 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/12/2014 3:10 PM, Steven Schveighoffer wrote:
 Sorry, saving 1-2 characters typing is really minor. This does not, in
 my opinion of course, have any significant improvement on usability for
 D. It simply does not carry it's own weight, and the potential to create
 bugs in the foreach handling would be not worth the risk.
While I agree on its triviality, I really doubt there's much "weight" to speak of either. Hara probably could've already implemented and tested this in the same amount of time any *one* of us have already spent bikeshedding it.
 While I do not see this as a showstopper for anyone, including, it
 doesn't warrant such vehement attack. It is a convenience feature that
 improves the overall experience of the D programmer. A plus in my mind
 and worthy of the time required to discuss, agree upon a solution and
 implement.
It's not an attack of any kind, it's just a rebuttal. It in no way reflects on the proposer or the defenders of the proposal. If there is some significant improvement to be shown, I happily would reconsider my position. Can you name a place where the improvement is more than just saving the typing of 'i', 'j', or 'k'? There are hundreds of such proposals made for D, and many of them are rejected due to the lack of improvement to the language. This is not a unique situation. The bar must be set high for new features, or we would have a mess of a language.
FWIW: I think this can be viewed more as "Lifting undue restrictions".
Jun 12 2014
next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 12 June 2014 at 19:26:47 UTC, Nick Sabalausky wrote:
 FWIW: I think this can be viewed more as "Lifting undue 
 restrictions".
For what it's worth, if any work is done on foreach, +1000 I think we should tackle the "important" issues first, such as: auto ref for foreach loops https://issues.dlang.org/show_bug.cgi?id=4707 https://issues.dlang.org/show_bug.cgi?id=10541 using ref foreach parameters with std.range.zip is a no-op Allow `ref` in `foreach` over range iff `front` returns by `ref` https://issues.dlang.org/show_bug.cgi?id=11934 Once foreach is something with can work correctly and reliably, then we can add the finishing touches (IMO)
Jun 12 2014
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Jun 2014 15:26:31 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:

 On 6/12/2014 3:10 PM, Steven Schveighoffer wrote:
 Sorry, saving 1-2 characters typing is really minor. This does not, in
 my opinion of course, have any significant improvement on usability for
 D. It simply does not carry it's own weight, and the potential to create
 bugs in the foreach handling would be not worth the risk.
While I agree on its triviality, I really doubt there's much "weight" to speak of either. Hara probably could've already implemented and tested this in the same amount of time any *one* of us have already spent bikeshedding it.
I don't think it's as trivial as you imply. You have to use a symbol that's valid, but isn't used in the subsequent loop to avoid collisions. -Steve
Jun 12 2014
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/12/2014 10:06 PM, Steven Schveighoffer wrote:

 I don't think it's as trivial as you imply. You have to use a symbol
 that's valid, but isn't used in the subsequent loop to avoid collisions.

 -Steve
Why would implicit local variables need unique names? This can be implemented by preventing identifiers named '_' to be inserted into the symbol table.
Jun 12 2014
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Jun 2014 17:41:36 -0400, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 06/12/2014 10:06 PM, Steven Schveighoffer wrote:

 I don't think it's as trivial as you imply. You have to use a symbol
 that's valid, but isn't used in the subsequent loop to avoid collisions.

 -Steve
Why would implicit local variables need unique names? This can be implemented by preventing identifiers named '_' to be inserted into the symbol table.
Of course, it doesn't HAVE to be that way. I would think it would be easier to implement. I don't know enough to judge which is easiest, but it doesn't sound trivial either way. -Steve
Jun 12 2014
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/12/2014 4:06 PM, Steven Schveighoffer wrote:
 On Thu, 12 Jun 2014 15:26:31 -0400, Nick Sabalausky
 <SeeWebsiteToContactMe semitwist.com> wrote:
 While I agree on its triviality, I really doubt there's much "weight"
 to speak of either. Hara probably could've already implemented and
 tested this in the same amount of time any *one* of us have already
 spent bikeshedding it.
I don't think it's as trivial as you imply. You have to use a symbol that's valid, but isn't used in the subsequent loop to avoid collisions.
Well, s/triviality/limited importance/ Slightly inaccurate word choice, whatever ;)
Jun 12 2014
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/12/14, 5:06 PM, Steven Schveighoffer wrote:
 On Thu, 12 Jun 2014 15:26:31 -0400, Nick Sabalausky
 <SeeWebsiteToContactMe semitwist.com> wrote:

 On 6/12/2014 3:10 PM, Steven Schveighoffer wrote:
 Sorry, saving 1-2 characters typing is really minor. This does not, in
 my opinion of course, have any significant improvement on usability for
 D. It simply does not carry it's own weight, and the potential to create
 bugs in the foreach handling would be not worth the risk.
While I agree on its triviality, I really doubt there's much "weight" to speak of either. Hara probably could've already implemented and tested this in the same amount of time any *one* of us have already spent bikeshedding it.
I don't think it's as trivial as you imply. You have to use a symbol that's valid, but isn't used in the subsequent loop to avoid collisions. -Steve
You normally do that by using names that the grammar doesn't allow as valid identifiers. Then you have a counter and prepend that. This way you never have name collisions.
Jun 12 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/12/2014 8:36 PM, Ary Borenszweig wrote:
 You normally do that by using names that the grammar doesn't allow as
 valid identifiers. Then you have a counter and prepend that. This way
 you never have name collisions.
And doesn't DMD *already* do a lot of that sorta thing already?
Jun 12 2014
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/12/14, 9:41 PM, Nick Sabalausky wrote:
 On 6/12/2014 8:36 PM, Ary Borenszweig wrote:
 You normally do that by using names that the grammar doesn't allow as
 valid identifiers. Then you have a counter and prepend that. This way
 you never have name collisions.
And doesn't DMD *already* do a lot of that sorta thing already?
That's why it surprises me that adding such a trivial feature is not done because it can lead to many bugs. You have a regressions test suite. Plus it's really trivial: if there's no loop variable, just define one automatically.
Jun 13 2014
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Steven Schveighoffer"  wrote in message 
news:op.xhcx4cb9eav7ka stevens-macbook-pro-2.local...

 I don't think it's as trivial as you imply. You have to use a symbol 
 that's valid, but isn't used in the subsequent loop to avoid collisions.
It is trivial, the frontend already has the ability to generate new unique identifiers. But I also don't think it's worth doing.
Jun 12 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/12/2014 11:00 AM, Manu via Digitalmars-d wrote:
 I often find myself wanting to write this:
    foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.

 You can do this:
    for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
I can't imagine this has ever been a significant issue for anyone. But that said, I certainly can't disagree with it, and wouldn't object to it.
Jun 12 2014
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/12/14, 3:04 PM, Nick Sabalausky wrote:
 On 6/12/2014 11:00 AM, Manu via Digitalmars-d wrote:
 I often find myself wanting to write this:
    foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.

 You can do this:
    for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
I can't imagine this has ever been a significant issue for anyone. But that said, I certainly can't disagree with it, and wouldn't object to it.
In Ruby/Crystal you can do: n.times do end In D you have to write: for(unused; 0..n) { } Doesn't it bother you that your language requires more typing and defining dummy variables just for doing something N times? Note, I'm just trying to point out that small improvements in the programmers life will be thanked a lot and more people will join your language.
Jun 12 2014
next sibling parent "Sebastiaan Koppe" <mail skoppe.eu> writes:
On Thursday, 12 June 2014 at 18:33:38 UTC, Ary Borenszweig wrote:
 On 6/12/14, 3:04 PM, Nick Sabalausky wrote:

 In Ruby/Crystal you can do:

 n.times do

 end

 In D you have to write:

 for(unused; 0..n) {

 }

 Doesn't it bother you that your language requires more typing 
 and defining dummy variables just for doing something N times?

 Note, I'm just trying to point out that small improvements in 
 the programmers life will be thanked a lot and more people will 
 join your language.
If you give me complete requirements, proper planning, effective communication, automated testing, fast compilation and a proper chair, I will program anything in the most horrid language you can think of.
Jun 12 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 6/12/2014 2:33 PM, Ary Borenszweig wrote:
 On 6/12/14, 3:04 PM, Nick Sabalausky wrote:
 On 6/12/2014 11:00 AM, Manu via Digitalmars-d wrote:
 I often find myself wanting to write this:
    foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.

 You can do this:
    for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
I can't imagine this has ever been a significant issue for anyone. But that said, I certainly can't disagree with it, and wouldn't object to it.
In Ruby/Crystal you can do: n.times do end In D you have to write: for(unused; 0..n) { } Doesn't it bother you that your language requires more typing and defining dummy variables just for doing something N times?
No. - It's a negligible amount of extra typing. - I find typing to be the most trivial and least time-consuming aspect of programming. - I rarely need to do that. Most of my "N times" loops exist *because* I want to use the index.
 Note, I'm just trying to point out that small improvements in the
 programmers life will be thanked a lot and more people will join your
 language.
I think you've misunderstood my previous post. I *agree* with Manu. I just don't think it's particularly significant.
Jun 12 2014
parent Jacob Carlborg <doob me.com> writes:
On 12/06/14 21:21, Nick Sabalausky wrote:

 - I rarely need to do that. Most of my "N times" loops exist *because* I
 want to use the index.
I use the "n.times" in Ruby for testing quite a lot. When I need to create x instances of a class and it doesn't matter what values they have. Although I usually use that together with a map. foos = 3.times.map{ Foo.new } -- /Jacob Carlborg
Jun 13 2014
prev sibling parent reply Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
V Thu, 12 Jun 2014 15:33:37 -0300
Ary Borenszweig via Digitalmars-d <digitalmars-d puremagic.com> napsáno:

 On 6/12/14, 3:04 PM, Nick Sabalausky wrote:
 On 6/12/2014 11:00 AM, Manu via Digitalmars-d wrote:
 I often find myself wanting to write this:
    foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.

 You can do this:
    for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is
 unused.
I can't imagine this has ever been a significant issue for anyone. But that said, I certainly can't disagree with it, and wouldn't object to it.
In Ruby/Crystal you can do: n.times do end In D you have to write: for(unused; 0..n) { } Doesn't it bother you that your language requires more typing and defining dummy variables just for doing something N times? Note, I'm just trying to point out that small improvements in the programmers life will be thanked a lot and more people will join your language.
No problem for me:
Jun 12 2014
next sibling parent "Craig Dillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 12 June 2014 at 22:38:26 UTC, Daniel Kozák via 
Digitalmars-d wrote:
 V Thu, 12 Jun 2014 15:33:37 -0300

 No problem for me:

That is sweet. Well done.
Jun 12 2014
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 12 June 2014 at 22:38:26 UTC, Daniel Kozák via 
Digitalmars-d wrote:
 No problem for me:

Would be nice if we could elide the parentheses and semicolons: 10.times! { writeln("Do It!"); } 10.times! (uint n) { writeln(n + 1, " Round"); }
Jun 13 2014
parent Jacob Carlborg <doob me.com> writes:
On 13/06/14 11:28, "Marc Schütz" <schuetzm gmx.net>" wrote:

 Would be nice if we could elide the parentheses and semicolons:

      10.times! {
          writeln("Do It!");
      }
      10.times! (uint n) {
          writeln(n + 1, " Round");
      }
Yeah, that has been suggested before. -- /Jacob Carlborg
Jun 13 2014
prev sibling parent "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 12 June 2014 at 22:38:26 UTC, Daniel Kozák via 
Digitalmars-d wrote:
 No problem for me:

Now put a break statement in the loop body.
Jun 13 2014
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 June 2014 04:04, Nick Sabalausky via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 6/12/2014 11:00 AM, Manu via Digitalmars-d wrote:
 I often find myself wanting to write this:
    foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.

 You can do this:
    for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
I can't imagine this has ever been a significant issue for anyone. But that said, I certainly can't disagree with it, and wouldn't object to it.
It gets awkward when you nest, using '_' leads to '__', and personally, I would expect an 'unreferenced variable' warning for the unused loop counter. I like warnings hassling me about unused variables. I also object to the inconsistency with for(;;). Recall Scott Myers talk... It's theoretically an optimisation too; capturing front may be a costly operation that's not required. Ranges maintain their counters internally, there's no reason to emit code to capture a local copy of 'front' if it's not used. popFront and empty don't imply a byVal copy, they usually just update range counters. I agree, it's trivial, just throwing it out there for opinion.
Jun 12 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Manu via Digitalmars-d"  wrote in message 
news:mailman.2111.1402626404.2907.digitalmars-d puremagic.com...

 It gets awkward when you nest, using '_' leads to '__',
i,j,k,etc work just fine. Are you really nesting your loops that deeply?
 and
 personally, I would expect an 'unreferenced variable' warning for the
 unused loop counter. I like warnings hassling me about unused
 variables.
This is a good point.
 I also object to the inconsistency with for(;;). Recall Scott Myers 
 talk...
Should we also allow "foreach(;)" ? 'for' being so loose is not necessarily something we want to copy.
 It's theoretically an optimisation too; capturing front may be a
 costly operation that's not required. Ranges maintain their counters
 internally, there's no reason to emit code to capture a local copy of
 'front' if it's not used. popFront and empty don't imply a byVal copy,
 they usually just update range counters.
The compiler's optimizer will do that just fine.
Jun 12 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Jun 2014 23:04:08 -0400, Daniel Murphy  
<yebbliesnospam gmail.com> wrote:

 "Manu via Digitalmars-d"  wrote in message
 and
 personally, I would expect an 'unreferenced variable' warning for the
 unused loop counter. I like warnings hassling me about unused
 variables.
This is a good point.
In this case, it's being "used" but not by the user. The comparison and increment are done behind the scenes. Note that unused variables typically are on function parameters and are silenced by naming the type but not the variable. This request is not in line with that, it is asking for elimination of the variable and the type, in one special case. If it were to be accepted, I'd push for foreach(x) instead of foreach(;0..x). Cut down all the noise, not just some of it.
 I also object to the inconsistency with for(;;). Recall Scott Myers  
 talk...
Should we also allow "foreach(;)" ? 'for' being so loose is not necessarily something we want to copy.
Completely different. foreach makes no sense without the second statement.
 It's theoretically an optimisation too; capturing front may be a
 costly operation that's not required. Ranges maintain their counters
 internally, there's no reason to emit code to capture a local copy of
 'front' if it's not used. popFront and empty don't imply a byVal copy,
 they usually just update range counters.
The compiler's optimizer will do that just fine.
foreach over a range doesn't make any sense unless you are using the data. This is a non-issue IMO. -Steve
Jun 12 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 June 2014 13:29, Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Thu, 12 Jun 2014 23:04:08 -0400, Daniel Murphy <yebbliesnospam gmail.com>
 wrote:

 "Manu via Digitalmars-d"  wrote in message
 and

 personally, I would expect an 'unreferenced variable' warning for the
 unused loop counter. I like warnings hassling me about unused
 variables.
This is a good point.
In this case, it's being "used" but not by the user.
The compiler doesn't use the result of front().
 The comparison and increment are done behind the scenes.
These use popFront() and empty(), not front().
 Note that unused variables typically
 are on function parameters and are silenced by naming the type but not the
 variable. This request is not in line with that, it is asking for
 elimination of the variable and the type, in one special case.
How is it a special case? It would be consistent with for(;;)
 If it were to be accepted, I'd push for foreach(x) instead of
 foreach(;0..x). Cut down all the noise, not just some of it.
Fine with me. I'd prefer this too.
 foreach over a range doesn't make any sense unless you are using the data.
 This is a non-issue IMO.
Who says? You can't possibly conceive of a case where the length is the only interesting property? (obviously I'm confronted by the case now, and not for the first time) You'd argue for foreach(_; 0..myRange.length)? That's pretty awkward. Some forward ranges don't have a known length, and can only be summed by an iteration sweep.
Jun 12 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Jun 2014 23:49:46 -0400, Manu via Digitalmars-d  
<digitalmars-d puremagic.com> wrote:

 On 13 June 2014 13:29, Steven Schveighoffer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Thu, 12 Jun 2014 23:04:08 -0400, Daniel Murphy  
 <yebbliesnospam gmail.com>
 wrote:

 "Manu via Digitalmars-d"  wrote in message
 and

 personally, I would expect an 'unreferenced variable' warning for the
 unused loop counter. I like warnings hassling me about unused
 variables.
This is a good point.
In this case, it's being "used" but not by the user.
The compiler doesn't use the result of front().
foreach(x; 0..5) translates to for(auto x = 0; x < 5; ++x) So there is no "front"
 The comparison and increment are done behind the scenes.
These use popFront() and empty(), not front().
I don't understand, 0..n is not a range.
 Note that unused variables typically
 are on function parameters and are silenced by naming the type but not  
 the
 variable. This request is not in line with that, it is asking for
 elimination of the variable and the type, in one special case.
How is it a special case? It would be consistent with for(;;)
foreach(x; 0..5) is a special case of foreach.
 If it were to be accepted, I'd push for foreach(x) instead of
 foreach(;0..x). Cut down all the noise, not just some of it.
Fine with me. I'd prefer this too.
 foreach over a range doesn't make any sense unless you are using the  
 data.
 This is a non-issue IMO.
Who says? You can't possibly conceive of a case where the length is the only interesting property? (obviously I'm confronted by the case now, and not for the first time)
Then use length or walkLength
 You'd argue for foreach(_; 0..myRange.length)? That's pretty awkward.
It's how I would do it, but I'd use 'i' instead of '_'
 Some forward ranges don't have a known length, and can only be summed
 by an iteration sweep.
-Steve
Jun 12 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 June 2014 14:14, Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Some forward ranges don't have a known length, and can only be summed
 by an iteration sweep.
That's inefficient, I might as well perform the iteration while I'm walking. No need for a whole pre-pass. Anyway, you don't need to show me how to work-around the issue. Of you think I'm not capable of figuring out workarounds myself, then I'm rather insulted. The point is, it's crappy, I see no real reason not to support foreach(; range) or foreach(range), it is already precedented by for(;;) (I was initially surprised by inconsistency, I'm sure I'm not alone). I was just throwing it out there as a thought.
Jun 12 2014
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 13 Jun 2014 01:27:24 -0400, Manu via Digitalmars-d  
<digitalmars-d puremagic.com> wrote:

 On 13 June 2014 14:14, Steven Schveighoffer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Some forward ranges don't have a known length, and can only be summed
 by an iteration sweep.
That's inefficient, I might as well perform the iteration while I'm walking. No need for a whole pre-pass.
It's the same complexity, O(n). I'm not sure how inefficient it is. Depending on what popFront does, the cache impact may actually make it perform better to do popFront in a tight loop, then do the iterations in a loop later.
 Anyway, you don't need to show me how to work-around the issue. Of you
 think I'm not capable of figuring out workarounds myself, then I'm
 rather insulted.
Please, don't feel insulted, I was not suggesting you didn't know how to work around the issue. It seemed you weren't aware of what walkLength did.
 The point is, it's crappy, I see no real reason not to support
 foreach(; range) or foreach(range), it is already precedented by
 for(;;) (I was initially surprised by inconsistency, I'm sure I'm not
 alone). I was just throwing it out there as a thought.
I will note that your original request (I thought) was specifically for foreach(;x..y), which is not a D range. I can't think of any useful cases where one wants to iterate over a range and not use the data in the range. The improvement to the language is minimal, but obviously not zero. I just don't think it's worth the benefit to change the syntax. That's all I'm saying. -Steve
Jun 13 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 June 2014 13:04, Daniel Murphy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 "Manu via Digitalmars-d"  wrote in message
 news:mailman.2111.1402626404.2907.digitalmars-d puremagic.com...


 It gets awkward when you nest, using '_' leads to '__',
i,j,k,etc work just fine. Are you really nesting your loops that deeply?
Giving explicit names pollutes the local namespace, and the point below about unreferenced variable warnings if you give explicit names.
 and
 personally, I would expect an 'unreferenced variable' warning for the
 unused loop counter. I like warnings hassling me about unused
 variables.
This is a good point.
 I also object to the inconsistency with for(;;). Recall Scott Myers
 talk...
Should we also allow "foreach(;)" ? 'for' being so loose is not necessarily something we want to copy.
Well, I don't think it really makes sense in the case of forach, for(;;) loops indefinitely in lieu of a termination condition, foreach(;) would theoretically be a noop. For each thing in nothing would iterate no things zero times; it should probably be an unreachable code warning, given the loop body wouldn't execute.
 It's theoretically an optimisation too; capturing front may be a
 costly operation that's not required. Ranges maintain their counters
 internally, there's no reason to emit code to capture a local copy of
 'front' if it's not used. popFront and empty don't imply a byVal copy,
 they usually just update range counters.
The compiler's optimizer will do that just fine.
Not necessarily. The range might be a lib, and non-pure. The compiler can't optimise/inline/eliminate the call if it doesn't have code. In my experience this is common, I frequently wrap C api's in D-style ranges. Potentially a lot of unnecessary calls to C_API_GetItem(itemIndex).
Jun 12 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Jun 2014 23:34:27 -0400, Manu via Digitalmars-d  
<digitalmars-d puremagic.com> wrote:

 On 13 June 2014 13:04, Daniel Murphy via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 i,j,k,etc work just fine.  Are you really nesting your loops that  
 deeply?
Giving explicit names pollutes the local namespace, and the point below about unreferenced variable warnings if you give explicit names.
i, j, k are traditionally loop variables. People have been using them for decades without conflicting their other variables.
 The compiler's optimizer will do that just fine.
Not necessarily. The range might be a lib, and non-pure. The compiler can't optimise/inline/eliminate the call if it doesn't have code. In my experience this is common, I frequently wrap C api's in D-style ranges. Potentially a lot of unnecessary calls to C_API_GetItem(itemIndex).
2 options: foreach(i; 0..r.walkLength) { } or while(!r.empty) { r.popFront(); } -Steve
Jun 12 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 June 2014 13:42, Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Thu, 12 Jun 2014 23:34:27 -0400, Manu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 13 June 2014 13:04, Daniel Murphy via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 i,j,k,etc work just fine.  Are you really nesting your loops that deeply?
Giving explicit names pollutes the local namespace, and the point below about unreferenced variable warnings if you give explicit names.
i, j, k are traditionally loop variables. People have been using them for decades without conflicting their other variables.
 The compiler's optimizer will do that just fine.
Not necessarily. The range might be a lib, and non-pure. The compiler can't optimise/inline/eliminate the call if it doesn't have code. In my experience this is common, I frequently wrap C api's in D-style ranges. Potentially a lot of unnecessary calls to C_API_GetItem(itemIndex).
2 options: foreach(i; 0..r.walkLength) { }
walkLength might not be known ahead of time. Lists?
 or

 while(!r.empty)
 {
    r.popFront();
 }
This modifies 'r', which foreach doesn't do. I'm forced to capture a copy for the sake of the loop? Sounds like a likely place for bugs to emerge... convert foreach code to this code as an optimisation, and a consecutive loop now terminates immediately changing program behaviour...
Jun 12 2014
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 12 Jun 2014 23:55:20 -0400, Manu via Digitalmars-d  
<digitalmars-d puremagic.com> wrote:

 On 13 June 2014 13:42, Steven Schveighoffer via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Thu, 12 Jun 2014 23:34:27 -0400, Manu via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 13 June 2014 13:04, Daniel Murphy via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 i,j,k,etc work just fine.  Are you really nesting your loops that  
 deeply?
Giving explicit names pollutes the local namespace, and the point below about unreferenced variable warnings if you give explicit names.
i, j, k are traditionally loop variables. People have been using them for decades without conflicting their other variables.
 The compiler's optimizer will do that just fine.
Not necessarily. The range might be a lib, and non-pure. The compiler can't optimise/inline/eliminate the call if it doesn't have code. In my experience this is common, I frequently wrap C api's in D-style ranges. Potentially a lot of unnecessary calls to C_API_GetItem(itemIndex).
2 options: foreach(i; 0..r.walkLength) { }
walkLength might not be known ahead of time. Lists?
walkLength is for ranges you don't know the length ahead of time. It executes the popFront/empty routines until exhaustion, returning the number of times popFront was required. And it should be trivial to create a wrapper that does not access front, but instead generates an index.
 or

 while(!r.empty)
 {
    r.popFront();
 }
This modifies 'r', which foreach doesn't do. I'm forced to capture a copy for the sake of the loop? Sounds like a likely place for bugs to emerge... convert foreach code to this code as an optimisation, and a consecutive loop now terminates immediately changing program behaviour...
Then use the first option. -Steve
Jun 12 2014
prev sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 13 Jun 2014 12:26:34 +1000
Manu via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 It gets awkward when you nest, using '_' leads to '__', and
 personally, I would expect an 'unreferenced variable' warning for the
 unused loop counter. I like warnings hassling me about unused
 variables.
I don't expect that to ever happen in D. There are too many places where variables are unused on purpose - especially in code used for template constraints (e.g. isInputRange has an unused variable in it). Having warnings about unused variables could then not only be counter-productive, but when combined with -w, they could easily break a lot of code.
 I also object to the inconsistency with for(;;). Recall Scott Myers
 talk...
Personally, I don't think that that should even be legal. while(1) works just as well without requiring any special cases.
 It's theoretically an optimisation too; capturing front may be a
 costly operation that's not required. Ranges maintain their counters
 internally, there's no reason to emit code to capture a local copy of
 'front' if it's not used. popFront and empty don't imply a byVal copy,
 they usually just update range counters.
That's an interesting idea. However, I would expect it to be a rare benefit, particularly when the primary use case is with integers. - Jonathan M Davis
Jun 12 2014
prev sibling next sibling parent "Mason McGill" <mmcgill caltech.edu> writes:
On Thursday, 12 June 2014 at 15:00:20 UTC, Manu via Digitalmars-d 
wrote:
 I often find myself wanting to write this:
   foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.

 You can do this:
   for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes 
 sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is 
 unused.
Seems like a nice idea. Especially useful when it comes to reading other people's code: foreach (i; 0..n) { some(); long(); list(); of(); tasks(); } // I always double back--"wait, where did they use `i`?"
Jun 12 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 12/06/14 17:00, Manu via Digitalmars-d wrote:
 I often find myself wanting to write this:
    foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.

 You can do this:
    for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
The only reason I can see to make this change is to make it more consistent with "for". But I don't know if it's "for" that is inconsistent with everything else or if it's "foreach" that is inconsistent with "for". -- /Jacob Carlborg
Jun 13 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 12 June 2014 at 15:00:20 UTC, Manu via Digitalmars-d 
wrote:
 I often find myself wanting to write this:
   foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.

 You can do this:
   for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes 
 sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is 
 unused.
Over 50 comments about minor syntax issue that makes no practical difference. D community never changes :P
Jun 13 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/13/2014 01:55 PM, Dicebot wrote:
 Over 50 comments about minor syntax issue ...
Including yours.
Jun 13 2014
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 13 June 2014 at 15:48:37 UTC, Timon Gehr wrote:
 On 06/13/2014 01:55 PM, Dicebot wrote:
 Over 50 comments about minor syntax issue ...
Including yours.
That was my first comment in this thread :O
Jun 13 2014
prev sibling next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 13/06/2014 3:00 a.m., Manu via Digitalmars-d wrote:
 I often find myself wanting to write this:
    foreach(; 0..n) {}
 In the case that I just want to do something n times and I don't
 actually care about the loop counter, but this doesn't compile.

 You can do this:
    for(;;) {}

 If 'for' lets you omit any of the loop terms, surely it makes sense
 that foreach would allow you to omit the first term as well?
 I see no need to declare a superfluous loop counter when it is unused.
Of course my reaction is a library solution: import std.stdio; import std.traits; void times(size_t n, void delegate() c) { for (size_t i = 0; i < n; i++) c(); } void times(size_t n, void delegate(size_t) c) { for (size_t i = 0; i < n; i++) c(i); } void iterate(T, U = typeof((T.init)[0]))(T t, void delegate(U) c) { foreach(v; t) c(v); } void iterate(T, U = typeof((T.init)[0]))(T t, void delegate(U, size_t) c) { foreach(i, v; t) c(v, i); } void main() { 4.times({ writeln("hi"); }); 4.times((i) { writeln("hello ", i); }); [1, 2, 3].iterate((uint c) { writeln("letter: ", c); }); [1, 2, 3].iterate((uint c, i) { writeln("letter: ", c, ", at: ", i); }); } But not really what you're wanting I'd imagine.
Jun 13 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
The idea of using code like this (only one or the other should be 
allowed) is rather natural, it breaks nothing, it avoids the 
programmer to introduce a variable that is not needed, making the 
code less noisy:

foreach (;0 .. 10) {...}
foreach (0 .. 10) {...}

I don't see the need for so many posts against this simple and 
innocous idea that's a small improvement. Improvements don't need 
to be large to be good, if their price is correspondingly small 
(as in this case). (With an attitude like the current one no 
small positive feature like the "_" to separate digits in numbers 
literals could have seen the light).


With a little breaking change "_" could become a name that can't 
be referenced, so you can also do:

foreach (_; 0 .. 10) { // OK
   foreach (_; 0 .. 20) { // OK
     writeln(_); // syntax error
   }
}


Or:

foreach (immutable i, _; items) {...}


The _ can also be used as "don't care" for tuple unpacking, this 
is a very important usage:

t{_, b} = fooAB();


And in switch on structs (that contain the optional "unapply" 
method):

switch (foo) {
   case Foo(x, _, _): writeln(x); break;
   default:
}



An alternative idea is to use "__", that is a reserved 
identifier. It's a little longer but I think it's still 
acceptable:


foreach (__; 0 .. 10) { // OK
   foreach (__; 0 .. 20) { // OK
     writeln(__); // syntax error
   }
}

foreach (immutable i, __; items) {...}

t{__, b} = fooAB();

switch (foo) {
   case Foo(x, __, __): writeln(x); break;
   default:
}


Bye,
bearophile
Jun 14 2014