[Feature Request] "first:" "last:" sections in a "foreach" block

[James Curran]

I'd like to make the following proposal for a new feature for the C#
language. I have no connection with the C# team at Microsoft. I'm posting
it here to gather input to refine it, in an "open Source" manner, and in an
attempt to build a ground-swell of support to convince the folks at
Microsoft to add it.
Proposal: "first:" "last:" sections in a "foreach" block

The problem:
The foreach statement allows iterating over all the elements of a
collection. However, often the first or last element of the collection must
be handled differently than the others in the collection. For example, if
we were generating a list of items for display, we'd want a comma after
every item except the last. In these cases, foreach cannot be used, and the
alternates which can be used are generally ugly and often less efficient
than foreach. An elegant solution keeping with the concept of C# is needed.

The proposal:
I suggest adding four new keywords (only available inside foreach block) to
direct the compiler to our exact intentions. "first:" "last:" "other:"
"all:"

Example:
foreach (Person p in personCollectio n)
{
first:
Console.WriteLi ne("Names: {0},", p.Name");
other:
Console.WriteLi ne(" {0},", p.Name");
last:
Console.WriteLi ne(" {0}", p.Name");
}
A block not preceeded by one of those keywords would be assumed to be an
"all:" block, exact as is the case now.

Analysis:
The advantages of the feature:
It solves a problem in an elegant way, keeping with the design concepts of
C#.
It is handled entirely by the compiler, so that it has ZERO effect on code
that does not use it, and it requires no changes to the class framework or
the CLR. (These were problems with other suggested solutions for this)

The disadvantages:
It requires four keywords, although this could be reduced to three
(eliminating "all:") and, they would each be very context sensitive, so the
conflicts with user-defined identifiers is unlikely.

Implementation:
Presently, a foreach construct is largely "syntactic sugar" around a while
loop using an IEnumerator, such that code written as
foreach (int i in arry)
{
Console.WriteLi ne(i);
}

Would be compiled much as if it were written:
IEnumerator n = arry.GetEnumera tor();
while(n.MoveNex t())
{
int i = (int) n.Current;
Console.WriteLi ne(i);
}

Similarly, code using these blocks would also have a direct translation:
foreach (int i in arry)
{
First:
Console.WriteLi ne("{0} - first", i);
Others:
Console.WriteLi ne(i);
}

Would be compiled as:
IEnumerator n = arry.GetEnumera tor();
if (n.MoveNext())
{
int i = (int) n.Current;
Console.WriteLi ne("{0}-- first ", i);
while(n.MoveNex t())
{
i = (int) n.Current;
Console.WriteLi ne(i);
}
}
(The internal representation of a "last:" block is a bit more involved, but
still basically straightforward )

Any comments are suggestion would be appreciated.

Truth,
James Curran
MVP (for .um. VC++)

[James Curran]

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

I think that for features like this the best way to explore the usage is to actually use them. Have you considered modifying mono or rotor and adding
the feature(or permutations of it)? It will give you, and others if you
release it, a chance to see how it would really work in real code.

Actually, it had never occured to my the source to a C# compiler would
be available. Though I'm not sure if I want to attempt adding features to
one. (But I have now downloaded the mono source, and will be looking into
it)

[Daniel O'Connell [C# MVP]]

"James Curran" <Ja*********@mv ps.org> wrote in message
news:uq******** ******@TK2MSFTN GP10.phx.gbl...

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

I think that for features like this the best way to explore the usage is to

actually use them. Have you considered modifying mono or rotor and adding
the feature(or permutations of it)? It will give you, and others if you
release it, a chance to see how it would really work in real code.

Actually, it had never occured to my the source to a C# compiler would
be available. Though I'm not sure if I want to attempt adding features to
one. (But I have now downloaded the mono source, and will be looking into
it)

LOL, ya, there is atleast mono's compiler(there is a compiler in rotor as
well, but its in C++(although you're probably better equiped to deal with it
than I) written in C#. I have done some fair amount of modification to the
mcs compiler(bout a half dozen experimental features), so I might be able to
help if you have any problems.

[James Curran]

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

I think that for features like this the best way to explore the usage is to actually use them. Have you considered modifying mono or rotor and adding
the feature(or permutations of it)? It will give you, and others if you
release it, a chance to see how it would really work in real code.

Actually, it had never occured to my the source to a C# compiler would
be available. Though I'm not sure if I want to attempt adding features to
one. (But I have now downloaded the mono source, and will be looking into
it)

[Daniel O'Connell [C# MVP]]

"James Curran" <Ja*********@mv ps.org> wrote in message
news:uq******** ******@TK2MSFTN GP10.phx.gbl...

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

I think that for features like this the best way to explore the usage is to

actually use them. Have you considered modifying mono or rotor and adding
the feature(or permutations of it)? It will give you, and others if you
release it, a chance to see how it would really work in real code.

Actually, it had never occured to my the source to a C# compiler would
be available. Though I'm not sure if I want to attempt adding features to
one. (But I have now downloaded the mono source, and will be looking into
it)

LOL, ya, there is atleast mono's compiler(there is a compiler in rotor as
well, but its in C++(although you're probably better equiped to deal with it
than I) written in C#. I have done some fair amount of modification to the
mcs compiler(bout a half dozen experimental features), so I might be able to
help if you have any problems.

[SpookyET]

This makes no sense, if you want access to the indexer, use a for loop.
foreach loops are 50% slower than for loops anyway, which means that you
should use them in very few cases.

[Tim Jarvis]

SpookyET wrote:

This makes no sense, if you want access to the indexer, use a for
loop. foreach loops are 50% slower than for loops anyway, which
means that you should use them in very few cases.

50%

That's a very specific number...where did you get that info from ?

Rgds Tim.

[Jon Skeet [C# MVP]]

Tim Jarvis <tj*****@NoSpam ForMe.com> wrote:

SpookyET wrote:

This makes no sense, if you want access to the indexer, use a for
loop. foreach loops are 50% slower than for loops anyway, which
means that you should use them in very few cases.

50%

That's a very specific number...where did you get that info from ?

And in what context? Depending on the type you're indexing, foreach can
be faster than using an indexer.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[SpookyET]

It isn't a real number. There is this episode of the .NET Show called
Code Optimizations at
http://msdn.microsoft.com/theshow/Ep...27/default.asp where it shows
you on how to optimize your code. A for loop took 1sec, forceach 1.5
secs, 2 secs. You can test it yourself by downloading the code and
playing with it. The fact is that foreach is way slower and it makes
sense to be slower. Take a look at the code behind forceach at
http://www.jaggersoft.com/csharp_standard/15.8.4.htm and see for yourself!

On Sat, 10 Apr 2004 10:17:17 -0700, Tim Jarvis <tj*****@NoSpam ForMe.com>
wrote:

SpookyET wrote:

This makes no sense, if you want access to the indexer, use a for
loop. foreach loops are 50% slower than for loops anyway, which
means that you should use them in very few cases.

50%

That's a very specific number...where did you get that info from ?

Rgds Tim.

[cody]

> It isn't a real number. There is this episode of the .NET Show called

Code Optimizations at
http://msdn.microsoft.com/theshow/Ep...27/default.asp where it shows
you on how to optimize your code. A for loop took 1sec, forceach 1.5
secs, 2 secs. You can test it yourself by downloading the code and
playing with it. The fact is that foreach is way slower and it makes
sense to be slower. Take a look at the code behind forceach at
http://www.jaggersoft.com/csharp_standard/15.8.4.htm and see for yourself!

This is not always true. for example with arrays a for loop should perform
with
the same speed as foreach since here are no Enumerators involved.

--
cody

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

[Daniel O'Connell [C# MVP]]

"cody" <pl************ *************@g mx.de> wrote in message
news:%2******** ********@tk2msf tngp13.phx.gbl. ..

It isn't a real number. There is this episode of the .NET Show called
Code Optimizations at
http://msdn.microsoft.com/theshow/Ep...27/default.asp where it shows
you on how to optimize your code. A for loop took 1sec, forceach 1.5
secs, 2 secs. You can test it yourself by downloading the code and
playing with it. The fact is that foreach is way slower and it makes
sense to be slower. Take a look at the code behind forceach at
http://www.jaggersoft.com/csharp_standard/15.8.4.htm and see for
yourself!

This is not always true. for example with arrays a for loop should perform
with
the same speed as foreach since here are no Enumerators involved.

Also, though I can't remember which structures specifically, there are cases
where foreach will result in better performance than for. Things like linked
lists, trees, etc may be faster via a foreach since its possible for the
foreach to be written so that it doesn't have to iterate the collection
every time. An indexer would.
--
cody

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