foreach enhancement

[cody]

What about an enhancement of foreach loops which allows a syntax like that:

foeach(int i in 1..10) { } // forward
foeach(int i in 99..2) { } // backwards
foeach(char c in 'a'..'z') { } // chars
foeach(Color c in Red..Blue) { } // using enums

It should work with all integral datatypes. Maybe we can step a bit further:

foeach(int i in 1..10, 30..100) { } // from 1 to 10 and 30 to hundred

And maybe we could also try to enhance the loop further and make it usable
for floating point types too:

foeach(float f in 1.0..9.5 : 0.5) { } // from 1.0 to 9.5 in steps of 0.5

This is far more readable as a for loop and makes the intend much clearer.
I always have to think if I write loops like "for (int i=list.Count-1; i<=0;
i--)".
This is unproductive and errorprone and hard to maintain. Thus, my proposal.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Daniel O'Connell [C# MVP]]

"Michael C" <no****@lol.net> wrote in message
news:jF*******************@news4.srv.hcvlny.cv.net ...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:#Z**************@tk2msftngp13.phx.gbl...

Note that back to back in's is a big reason why I was pushing for isin in
another portion of the thread.
Yeah, when I saw how the comprehensions interact with other code, the 'in'
problem became clear.

>
> Range = 1..5;
> List = [Range];
> Range = 6..10;
>

In that case its irrelevent.
Range = 6...10; creates a *new* object. You would just be replacing a
variables value, not the variable itself. IMHO, ranges should be
immutable
and joins should result in an entirely new range being generated.

That may be the case, but if we're assigning the range 1..5 to a variable,
and later assign the range 6..10 to the same variable... I suppose my
first
question is what happens to the original 1..5 range? I would expect that
(if it were an object) it would just be disposed of and the 6..10 range
replace it. The main question though was what does the variable List
contain after the instructions above? Is it [1..5], [6..10] or some other
value/values?

Tell me, what does
ArrayList list = new ArrayList();
string x="one";
list.Add(x);
x = "two";

what does Console.WriteLine(list[0]); write?
I see no reason to change existing behaviour here, a such the variable list
would be [1...5].

[Michael C]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP12.phx.gbl...

Tell me, what does
ArrayList list = new ArrayList();
string x="one";
list.Add(x);
x = "two";

what does Console.WriteLine(list[0]); write?
I see no reason to change existing behaviour here, a such the variable list would be [1...5].

That's what I was wondering. So you'll basically be assigning the value of
the variable to the list, as opposed to assigning the variable itself, like
happens with TreeViews and TreeNodes.

// Generates an error
TreeNode tvn = new TreeNode("Node A");
tvw.Nodes.Add (tvn);
tvn.Text = "Node B";
tvw.Nodes.Add (tvn);

[Daniel O'Connell [C# MVP]]

"Michael C" <mi*******@optonline.net> wrote in message
news:Oo**************@TK2MSFTNGP09.phx.gbl...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:%2****************@TK2MSFTNGP12.phx.gbl...

Tell me, what does
ArrayList list = new ArrayList();
string x="one";
list.Add(x);
x = "two";

what does Console.WriteLine(list[0]); write?
I see no reason to change existing behaviour here, a such the variable list

would be [1...5].

That's what I was wondering. So you'll basically be assigning the value
of
the variable to the list, as opposed to assigning the variable itself,
like
happens with TreeViews and TreeNodes.

// Generates an error
TreeNode tvn = new TreeNode("Node A");
tvw.Nodes.Add (tvn);
tvn.Text = "Node B";
tvw.Nodes.Add (tvn);

Well, in this case you are assigning a tree node variable to the tree view
and then changing one of it its properties. This isn't the same as creating
a new object in the variable tvn.
In the case of ranges, each range results in a new object being assigned to
the variable, and as such no issues like this.

[Michael C]

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:u4*************@TK2MSFTNGP10.phx.gbl...

Well, in this case you are assigning a tree node variable to the tree view
and then changing one of it its properties. This isn't the same as creating a new object in the variable tvn.
In the case of ranges, each range results in a new object being assigned to the variable, and as such no issues like this.

Yes, that's what I was trying to get clarification on. If, when you create
a list, it would be assigned the Range variable like a treeview node, or if
you would be assigning just the value of the variable, and if that would
require an ICloneable interface or not.

Thanks,
Michael C.

[Daniel O'Connell [C# MVP]]

"Michael C" <no****@lol.net> wrote in message
news:jE*********************@news4.srv.hcvlny.cv.n et...

"Daniel O'Connell [C# MVP]" <[e-mail]> wrote in
message news:u4*************@TK2MSFTNGP10.phx.gbl...

Well, in this case you are assigning a tree node variable to the tree
view
and then changing one of it its properties. This isn't the same as

creating

a new object in the variable tvn.
In the case of ranges, each range results in a new object being assigned

to

the variable, and as such no issues like this.

Yes, that's what I was trying to get clarification on. If, when you
create
a list, it would be assigned the Range variable like a treeview node, or
if
you would be assigning just the value of the variable, and if that would
require an ICloneable interface or not.

Nope, due to immutability of ranges I don't think this will be an issue. The
principal behind why is different but the result is the same.