Is it feasible to get some syntactic sugar for capturing the value only once?

[voroninp]

Consider this snippet:

void Main()
{
    var j = 0;
    var x = () => j;
    Console.WriteLine(x());
    j = 42;
    Console.WriteLine(x());
}

The second call to x() yields 42.

To prevent it, I must introduce another variable and capture it instead of j:

void Main()
{
    var j = 0;
    var jcopy = j;
    var x = () => jcopy;
    Console.WriteLine(x());
    j = 42;
    Console.WriteLine(x());
}

The problem is that it is still a variable, it pollutes the code, and generated implementation of the lambda has a mutable (not a read only) jcopy field while lambda applies no changes to it.

I'd like to be able to instruct compiler to do it automatically, so the value of j is captured only once:

void Main()
{
    var j = 0;
    var x = () => j#; // I have no idea about appropriate syntax, here it is just as an example.
    Console.WriteLine(x()); // prints 0
    j = 42;
    Console.WriteLine(x()); // prints 0
}

It gets even more interesting with complex types:

void Main()
{
    var j = DateTime.Now;
    var x = () => j.Ticks;
    Console.WriteLine(x());
    j = j.AddDays(1);
    Console.WriteLine(x());
}

Here I have a choice what kind of variable to introduce for the capture: jcopy: var jcopy = j.Ticks; or var jcopy = j;
Same should be able with the sugar:

void Main()
{
    var j = DateTime.Now;
    var x = () => j#.Ticks;
    Console.WriteLine(x());
    j = j.AddDays(1);
    Console.WriteLine(x());
}

vs

void Main()
{
    var j = DateTime.Now;
    var x = () => j.Ticks#;
    Console.WriteLine(x());
    j = j.AddDays(1);
    Console.WriteLine(x());
}

For the latter case compiler could generate:

[CompilerGenerated]
private sealed class <>c__DisplayClass4_0
{
    private readonly long jcopy;
	
    internal <>c__DisplayClass4_0(long jcopy)
    {
        this.jcopy = jcopy;
    }

    internal long <Main>b__0()
    {
        return jcopy;
    }
}

[jaredpar]

In the past we've discussed the idea of adding a modifier that would cause closures to capture by value instead of by reference. These are tweaks that exist in other languages like C++. That would provide the semantics that you want in this particular case.

The general feeling though was that it's not worth the conceptual trade off to add to the language.

[GabeSchaffer]

Here are how some other languages have dealt with the issue:

• In Java, you can only capture variables you don't reassign (effectively read-only), so they don't have to distinguish between capturing by value or by reference. I'm glad C# didn't go that route.
• F# captures by value, and won't let you capture a variable declared mutable, but you can create a reference (i = ref 12) and capture that. C# already defaults to capturing references.
• Objective-C 2.0 blocks capture by value unless you declare a variable for capture by ref, like __block int i = 12;.
• In C++, you specify on a per-lambda basis whether it captures variables by value, by reference, or not at all. Variables captured by value are read-only by default, but you can declare them mutable. You can also specify capture on a per-variable basis, and even define new variables within the capture specification! While flexible, its syntax isn't very intuitive, and way more than I think C# should implement. Here's an example from the spec:

int x = 4;
auto y = [&r = x, x = x + 1]() -> int
{
    r += 2;
    return x * x;
}(); // updates ::x to 6 and initializes y to 25.

• Generally speaking, in languages that capture by reference (e.g. C#, Python, JS), prior to defining the lambda you create a copy of the variable you want to capture by reference and then don't modify it. This is great because it works with no additional work from the language, but is a maintenance issue because somebody may come along and remove the "unnecessary" variable.

I don't know of any language that defaults to capture by reference but allows you to override that, so there isn't a good example to look towards for inspiration. It's interesting that F# and Objective-C let you choose at the variable's declaration site, C++ lets you choose at the lambda definition site, and the suggestion in this discussion had the choice made at the point where the captured variable is used.

[voroninp]

I didn't know about F#'s behavior. Nice!

[TahirAhmadov]

#8479

I think it's related to readonly locals. It's better to use an analyzer (as discussed in that thread and elsewhere) to default to readonly locals, and it'll force you to create another variable to avoid bugs. Yes, it's a little boilerplate, but I think it would be beneficial in other ways, too, to adopt the readonly style of coding. (Disclosure: I haven't made the switch yet, but in my defense I'm pretty busy these days.)

[The-Futurist]

@voroninp

        static void Main(string[] args)
        {
            var j = 0;

            var x = Capture(j); 

            Console.WriteLine(x());

            j = 42;

            Console.WriteLine(x());
        }

        static Func<T> Capture<T>(T arg)
        {
            return () => arg;
        }

[voroninp]

Yes, replacing vars with lambdas like this helps with immutability , but increases memory allocations.

[The-Futurist]

There are other variants as well

        static void Main(string[] args)
        {
            var j = 17;

            var x = Capture(() => j); 

            Console.WriteLine(x());

            j = 42;

            Console.WriteLine(x());
        }

        static Func<T> Capture<T>(T arg)
        {
            return () => arg;
        }

        static Func<T> Capture<T>(Func<T> arg)
        {
            var local = arg();
            return () => local;
        }