Counter variable in foreach loop

[xsoheilalizadeh]

A feature to define counter variable in foreach loop, something like:

 foreach (var item in items; int counter = 0) 
 {
     counter++;
  
     Console.WriteLine (counter);
 }

currently we can use following way:

 var counter = 0;

 foreach (var item in items) 
 {

      counter++;
   
      Console.WriteLine (counter);
 }

[TonyValenti]

As a more general solution, I'd prefer to see the For-Each solution support blocks in its regions.

            for ({ var IE = List.GetEnumerator(); int Index = 0; } ; IE.MoveNext() ; Index++) {
                 Console.WriteLine($"{Index}:  {IE.Current}");
            }

[TonyValenti]

This is some code that I use too:

 public class SelectIndexResult<T> {
        public T Value { get; set; }
        public int Index { get; set; }
    }

    public static class CollectionExtensions {

        public static IEnumerable<SelectIndexResult<T>> WithIndexes<T>(this IEnumerable<T> This) {
            return This.Select((Item, Index) => new SelectIndexResult<T>() {
                Value = Item,
                Index = Index,
            });
        }
}

[ufcpp]

https://gist.github.com/ufcpp/2b3e1a5821169f6b21ded175ad05c752#file-program-cs-L25

[svick]

I think that a tuple-based Indexed extension method, like the one shown by @ufcpp, should be added to Enumerable. This lets you access the index inside a foreach, and does not require any changes to the language.

[ethanae]

Why not use Select to map a collection which gets the current object and the index passed in?

list.Select((element, index) => { ... })?

https://stackoverflow.com/a/2471611/4716488

[ufcpp]

@ethanae
To avoid allocation, it would be better using struct https://gist.github.com/ufcpp/2b3e1a5821169f6b21ded175ad05c752#file-a-cs-L6

[jnm2]

I call mine AsIndexed() =)

[bondsbw]

@TonyValenti Your for syntax might be provided via #377.

[DavidArno]

@jnm2,
Mine is just called Indexed() 😄

As @svick says, it would be good to have the core libraries add this to IEnumerable<T> as an extension method, or as a default method implementation when we get that feature.

[TheUnlocked]

Counter proposal:

 foreach (var item in items; in int counter) 
 {
     Console.WriteLine(counter);
     Console.WriteLine(item);
 }

This would allow the user to access the counter, but not actually effect it. If they want to manipulate the counter, they should really just use a for loop. However, the user should still be able to access the counter.

readonly might also be a better keyword instead of in. Having no keyword (or an optional keyword) could also work, as long as the counter is still unchangeable.

[svick]

@TheUnlocked

That's confusing, since foreach already uses in with different meaning.

Also, the iteration variable of a foreach loop is readonly, but doesn't have any modifier indicating that, so that would be inconsistent.

[bondsbw]

Another counter counter-proposal: 😛

foreach (var item[index] in items) 
{
     Console.WriteLine(index);
}

(Edited, we shouldn't be incrementing, that can be handled automatically.)

[TheUnlocked]

I agree that in was probably not the best choice. However, if it's just int counter without any modifier, my concern is that there would be an implication that it's just like any other variable, which wouldn't be true. Requiring readonly or in would get the message across, though as you pointed out, in could be confusing.

The difference between them as I would interpret it on first glance is:
Nothing: Isn't readonly; same variable for the entire loop
in: Readonly; same variable for the entire loop
readonly: Readonly; different variable for each iteration

The difference between the latter two won't be important in most cases, but could be important in some.

Edit: I suppose as an alternative, it could be up to the user to decide which they want for their use case.

[TonyValenti]

I liked the in proposal but i thought it should have been an out var.

On Fri, Jun 1, 2018 at 6:10 PM Unlocked ***@***.***> wrote: I agree that in was probably not the best choice. However, if it's just int counter without any modifier, my concern is that there would be an implication that it's just like any other variable, which wouldn't be true. Requiring readonly or in would get the message across, though as you pointed out, in could be confusing. The difference between them as I would interpret it on first glance is: Nothing: Isn't readonly; same variable for the entire loop in: Readonly; same variable for the entire loop readonly: Readonly; different variable for each iteration — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/dotnet/csharplang/issues/1584#issuecomment-394032337>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AM-qVpH-qxxOZwGYc5WO5Yq9OPUHqiMGks5t4cnmgaJpZM4UUvCj> .

-- Always glad to help, [image: AlphaDrive for Clio] <https://www.alphadriveforclio.com/> Tony Valenti Software Engineer T: 402-401-7568 <javascript:void(0);> E: [email protected] W: www.AlphaDriveForClio.com <https://www.alphadriveforclio.com/> Schedule a Meeting with Me <https://www.alphadriveforclio.com/schedule-meeting> This message contains confidential information and is intended only for the intended recipients. If you are not an intended recipient you should not disseminate, distribute or copy this e-mail. Please notify us immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.

[jnm2]

One line of reply, 44 lines of email boilerplate. 😄

[sirgru]

Other languages have this useful feature:
Go:

for index, element := range someSlice {
    // index is the index where we are
    // element is the element from someSlice for where we are
}

Swift:

for (index, element) in list.enumerated() {
  print("Item \(index): \(element)")
}

D:

foreach (i, e; [4, 5, 6]) {
    writeln(i, ":", e);
}
// 0:4 1:5 2:6

They all put the indexer before the variable which I find weird. I like this syntax best:

	foreach(var item @ index in collection ) {
		...
	}

The extension methods on IE have negative performance characteristics just for one indexer. I think this should be a standard language feature.

[CyrusNajmabadi]

The extension methods on IE have negative performance characteristics just for one indexer

Why is that the case?

If you have:

public struct IndexedEnumerable<T> 
{
    private readonly IEnumerable<T> values;

    public IndexedEnumerable(IEnumerable<T> values)
        => this.values = values;

    public Enumerator GetEnumerator()
        => new Enumerator(values.GetEnumerator());

    public struct Enumerator
    {
        private readonly IEnumerator<T> enumerator;
        public int index;

        public Enumerator(IEnumerator<T> enumerator)
        {
            this.enumerator = enumerator;
            index = -1;
        }

        public bool MoveNext()
        {
            index++;
            return enumerator.MoveNext();
        }

        public (int, T) Current => (index, enumerator.Current);
    }
}

public static class Enumerable
{
    public static IndexedEnumerable<T> Indexed<T>(this IEnumerable<T> values)
        => new IndexedEnumerable<T>(values);
}


class Test
{
    static void Main(string[] args)
    {
        foreach (var (index, val) in args.Indexed())
        {

        }
    }
}

Then that should be pretty darn fast. There are no actual allocations going on here.

--

For those concerned about what happens if you have an existing struct-enumerator to work with, then Shapes helps solve that becuase you'd write the above with SEnumerable and SEnumerator instead, giving you a shape-based way to do this with almost no perf overhead.

So, in other words, i don't think we actually need this proposal, because it can be done today already with existing langauge features (or subsumed into other upcoming language features).

[CyrusNajmabadi]

They all put the indexer before the variable which I find weird. I like this syntax best:

That makes sense to me. If i iterate a dictionary, i get Key-Values, not Value-Keys. For a sequence, the key is the index. So i get Index-Value, not Value-Index.

[CyrusNajmabadi]

Note: if we ever get struct-enumeration in the language, tehn the above could just be written as:

public static class Enumerable
{
  public static struct IndexedEnumerable<T> Indexed<T>(this IEnumerable<T> values)
  {
    int index = 0;
    foreach (var val in values)
    {
      yield return (index++, val);
    }
}

But until then, manually writing it out is the way to go.

[sirgru]

That makes sense to me. If i iterate a dictionary, i get Key-Values, not Value-Keys. For a sequence, the key is the index. So i get Index-Value, not Value-Index.

I get the logic. I guess it makes more sense when value is a tuple, so it's like a KVP. However, my logic was: there are plenty of cases where index doesn't logically correspond to a Key, for example when iterating dictionaries themselves (which wouldn't make much sense but still). If the indexer comes later like in my syntax it feels in some way like an optional parameter - the optional stuff comes last. So there is a foreach like it is today and the foreach with an indexer which is optional. It also reads much better imo.

Then that should be pretty darn fast. There are no actual allocations going on here.

I agree. But my understanding is with simple collections such as lists and arrays the compiler makes optimizations to not threat them through an IE interface, instead iterates over them like in a for loop, where foreach becomes only syntactic sugar. In this case such optimization cannot be made.

[CyrusNajmabadi]

I agree. But my understanding is with simple collections such as lists and arrays the compiler makes optimizations to not threat them through an IE interface, instead iterates over them like in a for loop, where foreach becomes only syntactic sugar. In this case such optimization cannot be made.

I mentioned this bit:

For those concerned about what happens if you have an existing struct-enumerator to work with, then Shapes helps solve that becuase you'd write the above with SEnumerable and SEnumerator instead, giving you a shape-based way to do this with almost no perf overhead.

So, in other words, i don't think we actually need this proposal, because it can be done today already with existing langauge features (or subsumed into other upcoming language features).

[ekolis]

Throwing my hat into the ring for a syntax suggestion:

var list = new string[]{"a", "b", "c"};
foreach (var q, i in list)
{
    Console.WriteLine($"item {i} is {q}");
}

[theunrepentantgeek]

Issue #3194 would enhance they way foreach looks for an implementation pattern, in the same way that asyc and deconstruction is already pattern based.

If that lands in C#, a simple extension method would make iteration with an index trivial, no other new syntax for C# required.

First, write a suitable extension method:

public static IEnumerator<(T, int)> GetEnumerator<T>(this IEnumerable<T> items)
{
    int index = 0;
    foreach(var i in items)
    {
        yield return (i, index++);
    }
}

and then you can iterate over any sequence using a tuple:

foreach ( var (Person, int) in FindPeople()) { ... }

or, perhaps preferably,

foreach ((Person p, int i) in FindPeople()) { ... }

An independent enhancement to the compiler to make the implementation of GetEnumerator() based on a struct may event allow this to be allocation free.

[333fred]

Fwiw @YairHalberstadt has an implementation pr out that is in the process of being reviewed, and if everything goes nicely I hope it'll be in 9. No guarantees, but that's my hope.

[YairHalberstadt]

@theunrepentantgeek I don't think that will work, since to preserve backwards compatibility IEnumerable is preferred over an extension GetEnumerator, and besides it is not target typed.

[theunrepentantgeek]

That's a shame.

When I skimmed through #3194, I thought it would fall back to the extension GetEnumerator() if using the one built into the type didn't compile, allowing this scenario.

Apologies for misreading it.

[Ramobo]

How about this slightly modified version of the original proposal?

foreach (Foo foo in foos; index) // `index` is implicitly a read-only `int`. Allow custom name for the case of nested loops, and for consistency with `for`.
{
    Console.WriteLine($"[{index}] {foo}");
}

// Translates to:
using (IEnumerator<Foo> enumerator = foos.GetEnumerator())
{
    int index = 0;

    while (enumerator.MoveNext())
    {
        Foo foo = enumerator.Current;

        Console.WriteLine($"[{index}] {foo}");

        index++;
    }
}

[seanblue]

What would it take to add the tuple foreach syntax into the language itself instead of having to rely on an extension method?

Extension method example from above:

foreach (var (item, index) in collection.Indexed())
{
    DoSomething(item, index);
}

Proposal:

foreach (var (item, index) in collection)
{
    DoSomething(item, index);
}

I'd like the language itself to contextually return T or a tuple (T, int) in the foreach simply based on which var (or hard type) is declared to the left of the in.

I think this approach is most consistent with current C# functionality because it's the same syntax used in Select and extension methods like above.

[Thaina]

I would say anything it take does not worth it. This feature could be solved easily with a little extension method. So changing the compiler just for that is absolutely overkill

Not to mention it was not intuitive that foreach can provide index if you just put a tuple at it. And it ambiguous that the object was the tuple itself or you want index of it

[HaloFour]

It would take the language design team to agree, and so far they don't.

Note that your proposal would be ambiguous if the enumerator already returned a tuple. It also wouldn't work for non-generic enumerables.

[seanblue]

Note that your proposal would be ambiguous if the enumerator already returned a tuple.

@HaloFour I don't think that's the case. The compiler would have to detect the actual generic type. If the IEnumerable's generic type is already (for example) (string, int), then the foreach could loop over (string a, int b) or ((string a, int b), int index). I think that's pretty understandable, personally.

It also wouldn't work for non-generic enumerables.

This part I can't really comment on though. I'm not sure what all the limitations are for non-generic enumerables because I almost always avoid using them. If this makes the proposal unworkable, so be it.

This feature could be solved easily with a little extension method. So changing the compiler just for that is absolutely overkill

@Thaina To be fair though, a significant portion of new C# features are syntactic sugar that don't actually add new functionality, but do (depending on your view) make things more convenient.

[Thaina]

@seanblue

new C# features are syntactic sugar that don't actually add new functionality

Every feature is syntactic sugar. But most of them provide high level of convenient without great alternative

My point is

This feature could be solved easily with a little extension method

This alternative is not complex enough to require introducing a new language feature just to solve it

If, as in the olden day we don't have tuple and tuple deconstruction nor extensoin method, I might consider that any alternative is not appeased. But now we already have all of those and just 8-10 characters could be saved is not important enough to introduce compiler change in the language itself

[Thaina]

Another benefit of using extension method over syntax is you can chain it with linq and clearly understand what it is

// suppose there is Select that return (item,index)
foreach(var ((item,i),count) in list.Select().Where((pair) => pair.item.IsWhatIWant).Select())
{
    // i is original index in the list
    // count is number of filtered/sorted
}

[cheong00]

I think we should do the change on for loop rather then foreach loop because not all IEnumerator interface implementations implements .Item[Index] as member (say, Hashtable or most key-based collections)

And for collections like Tree which we can have multiple transversal methods (and typically implements IEnumerator), index doesn't really have meaning there.