Add support for Discards inside a foreach loop (underscore syntax, placeholder variables)

[AlexRadch]

Add support for Discards inside a foreach loop (underscore syntax, placeholder variables).

One of the next:

foreach(_ in Enumerable.Range(0, 10))
    foreach(_ in Enumerable.Range(0, 10))
        Console.WriteLine("🌄"); // 100 times

[DavidArno]

Do you have any real-world use cases for this? My gut feeling is that scenarios where one needs to repeat something 100 times without reference to a counter seem likely vanishingly rare.

[KennethHoff]

Ah, I guess using something like the following pseudo code?

object? _;

foreach (_ in ..)

Never thought using a pre-existing variable like that before.

[HaloFour]

Actually that's not legal, so that would in theory be a case where the compiler could support discards unambiguously, if the team considered it worthwhile.

The fact that _ is still considered a valid identifier is why it's not universally treated as a discard.

[DavidArno]

The fact that _ is still considered a valid identifier is why it's not universally treated as a discard.

You never know, one day #7033 might happen and then _ could stop being considered a valid identifier. Emphasis on "could" though as from previous conversations, I definitely got the impression that the language team are not interested in using it to "fix the mistakes of the past" by preventing var, await, _ etc being used as identifiers.

[AlexRadch]

The fact that _ is still considered a valid identifier is why it's not universally treated as a discard.

If _ is not declared, it is used as discards, but not for the foreach loop. I suggest adding this rule to the foreach loop as well.

[333fred]

definitely got the impression that the language team are not interested in using it to "fix the mistakes of the past" by preventing var, await, _ etc being used as identifiers.

Depends on what you mean by mistakes of the past. That proposal grew out of desire to fix some of the semantic ambiguity around those specific identifiers. But it's certainly not intended to be used as a broad hammer.

[theunrepentantgeek]

If this was a true discard, where no reference was kept to the item for the current iteration, then it would be eligible for garbage collection.

Now, if you're iterating Enumerable.Range(0, 10) there's nothing on the heap to collect.
And if you're iterating List<T> (or another collection), then the collection retains the references for you.

But if you're iterating some kind of factory that implements IEnumerable<T> you start getting into uncertain territory.

With this:

foreach (var case in factory.GenerateCases()) 
{
     // ....
}

each generated case lives in a local variable and definitely won't be garbage collected prior to the end of the iteration.

Same applies to this:

foreach (var _in factory.GenerateCases()) 
{
     // ....
}

where _ is a variable.

Change _ to a discard though, and the value returned from the factory is simply discarded (by definition), and thus eligible for the GC to do its' thing at any time through the iteration - triggering any finalizers.

Having spent a migraine inducing few days tracking down a problem precisely like this, where a dropped reference resulted in early GC when the server was under load (the bug was not easily reproduced on my dev machine), I can assure you this would be no fun at all.

The obvious fix would be for the compiler to still emit a variable behind the scenes, at which point the generated code is precisely the same and all we've gained is a the ability to delete a few characters from maybe 1% of foreach loops.

[AlexRadch]

If this was a true discard, where no reference was kept to the item for the current iteration, then it would be eligible for garbage collection.

Change _ to a discard though, and the value returned from the factory is simply discarded (by definition), and thus eligible for the GC to do its' thing at any time through the iteration - triggering any finalizers.

This depends on whether the compiler now has the right to cut out the call to the Current property if the result is not used further. I think the compiler will use Current property and will create a hidden variable until the end of the loop.

The obvious fix would be for the compiler to still emit a variable behind the scenes, at which point the generated code is precisely the same and all we've gained is a the ability to delete a few characters from maybe 1% of foreach loops.

I think less than 1%, but C# will become more consistent.

[svick]

With this:

foreach (var case in factory.GenerateCases()) 
{
     // ....
}

each generated case lives in a local variable and definitely won't be garbage collected prior to the end of the iteration.

That's not true. An object that's referenced by a local variable can still be GCed, if the runtime can determine that the value will never be accessed.

To demonstrate, consider this program:

using System;
using System.Collections;
using System.Collections.Generic;

var factory = new Factory();

foreach (var @case in factory.GenerateCases())
{
     GC.Collect();
     GC.WaitForPendingFinalizers();

     Console.WriteLine("end of the iteration");

     break;
}

class Factory
{
    public IEnumerable<Case> GenerateCases() => new Cases();
}

class Cases : IEnumerable<Case>, IEnumerator<Case>
{
    public Case Current => new();

    object IEnumerator.Current => Current;

    public bool MoveNext() => true;

    public void Reset() { }

    public void Dispose() { }

    public IEnumerator<Case> GetEnumerator() => this;

    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
}

class Case
{
    ~Case() => Console.WriteLine("Case finalized");
}

(Note that it's fairly unusual, but still valid, for an implementation of IEnumerator<T> to not keep the Current value in a field.)

Running it (with dotnet run -c release) produces the following output for me:

Case finalized
end of the iteration

This shows that the iteration variable of a foreach can be finalized and GCed even before its iteration ends.

[theunrepentantgeek]

I think less than 1%, but C# will become more consistent.

Consistency isn't of itself a key goal of the design of C#. It's an important thing to consider when doing feature design, for sure, but it's far short of being a sufficient reason to change things.

[theunrepentantgeek]

An object that's referenced by a local variable can still be GCed, if the runtime can determine that the value will never be accessed.

Yes! I'd forgotten this detail. I remember a investigating particularly nasty bug that came down to exactly this - causing early finalization of an active connection causing frequent but unpredictable issues in production. I didn't have an easy repro in my dev environment until after we identified what was going wrong. Fun times - for a very particular definition of the word fun.