Repeat statement

Topics: C# Language Design
May 6, 2014 at 12:22 AM
Edited May 6, 2014 at 12:34 AM
In order to repeat a block of statements we have many ways like for, foreach, while, and do-while.

For cases where you need to constantly execute the block without interrupting it with break or return for a constant number of times, it would be nice to count with an expression like:
repeat(<constantNumberOfTimes>)
{
  ...
} 
and or even
repeat(long limit=<constantNumberOfTimes>, index)
{
  ...
} 
May 6, 2014 at 1:46 AM
I think this would probably be better as a variant on for. Otherwise repeat looks too much like a method call (the only thing distinguishing it from a method call is the missing semicolon).
May 6, 2014 at 12:00 PM
Personally, I use
foreach (var i in Enumerable.Range(0, count))
{
    ...
}
I think a repeat keyword would be too much. It would be sufficient, and better, to have range literals, like 0..10.
foreach (var i in 0..10)
{
    ...
}
But if we go that way, why not also regex literals like /foo.*/i, dict literals like { 'a' : 42 } and array literals like [1,2,4]?
C# was designed to look familiar to C++ users, so it is probably too much to expect a syntax as short and convenient as in Ruby or Python.
May 6, 2014 at 3:07 PM
This seems totally gratuitous to me. for(int i = 0; i < 10; i++) is pretty much lesson number 1 in any programming course. What you're asking for is essentially a less powerful for loop useful in only a narrow scenario.
May 6, 2014 at 3:42 PM
MgSam wrote:
This seems totally gratuitous to me. for(int i = 0; i < 10; i++) is pretty much lesson number 1 in any programming course. What you're asking for is essentially a less powerful for loop useful in only a narrow scenario.
A VB.NET loop For I=1 to Limit may look like for(var i=1; i<=Limit; i++) but there are a couple of important semantic differences:
  1. The VB.NET For loop will make I read-only during its scope; the C and C# for loops will do no such thing.
  2. The VB.NET For loop will sample the ending value once. The C and C# for loops will re-evaluate the ending condition on every pass.
Although it's pretty common for optimizers to detect certain common patterns with a C-style for loop in cases where they can ascertain that neither the indexing variable nor the loop upper limit can change within the loop, I think it's generally better to specify such things rather than have a compiler infer them. Further, I would suggest that it's helpful for a programmer to be able to look at a For statement and know that the the loop variable and ending conditions won't be modified during the loop; while coding conventions might generally favor using while rather than for in cases where either of those things could be modified, compilers enforce no such rules and the only way to know whether i or Limit might change during the above loop would be to inspect all the code for the loop.
May 6, 2014 at 3:48 PM
@MgSam: Yes, I am, so?

@eldritchconundrum: I like your suggestion, too.

@supercat: indeed.
May 6, 2014 at 4:19 PM
the only way to know whether i or Limit might change during the above loop would be to inspect all the code for the loop.
@supercat If you're writing reasonable code with terse loop bodies, the inside of a for loop should be pretty trivial to see if the loop variable is changing. And in the narrow use case for the proposed feature, the ending condition doesn't change.

@Ultrahead So, in my opinion, the cost of more syntax and a narrow use case does not outweigh the benefit.

More generally - how often do you find yourself actually writing code where you need to repeat something a pre-determined number of times or actually need access to a counter? I think most people would say the answer is "rarely". That was the whole point of the invention of foreach and similar in other languages- you rarely care about the index, you really want to just enumerate a collection most of the time. I don't think the rare cases you do want an index or a set number of repetitions warrants new syntax. This seems to me like a solution looking for a problem.
May 6, 2014 at 4:38 PM
Edited May 6, 2014 at 4:56 PM
@MgSam: if that is the case, then I must assume that you are against every syntactic sugar that MSFT is bringing to C#.

Plus, in this case, it is more than that, since as supercat inferred, I do not need a read-write local variable nor to re-evaluate conditions.
May 6, 2014 at 5:45 PM
@Ultrahead On the contrary, I'm very much supportive of syntax sugar features that I believe solve common problems by making code less verbose or more readable. I think what sets C# apart from many other languages is that a major tenant of its language design has been "solve real problems" rather than do things because they are interesting from a theory standpoint.
May 6, 2014 at 6:26 PM
Edited May 6, 2014 at 6:35 PM
Well, many syntactic sugar comes to improve common situations than solving problems, unless you consider "having to write more code" a problem or a real problem to solve.

In either case, regarding lesson 1 above, a syntax like repeat(constant){ } is far less verbose, more readable and a time saver, that is of course, at least in my case.