Introduce syntax in lambda to capture by value rather than by reference

[thomaslevesque]

In C#, when a lambda captures a local, it always captures the variable, not the value. In C++, captures are specified explicitly, and it's possible to indicate whether a given variable should be captured by reference or by value.

It would be useful to have a keyword (e.g. valueof) to tell the compiler to capture the value rather than the variable:

// Captures the variable
var foo = GetFoo();
Func<int> func1 = () => foo;
Expression<Func<int>> expr1 = () => foo;

// Captures the value
var foo = GetFoo();
Func<int> func2 = () => valueof(foo);
Expression<Func<int>> expr2 = () => valueof(foo);

In an expression tree, valueof(foo) would be a ConstantExpression with the value of foo at the time the expression is created.

[HaloFour]

What is this proposal attempting to achieve? Why would it be beneficial to change how the variable is captured and how would it differ from how the capture works today?

[thomaslevesque]

@YairHalberstadt I think you misunderstood my point (maybe I didn't express it clearly).

When a variable is captured in a lambda, the variable is hoisted as a field in a closure type. Accessing the variable in the lambda actually accesses that field, and returns whatever value the field has at this point in time. It's "by reference" in the sense that it doesn't make a copy of the value when the lambda is created.

[YairHalberstadt]

@thomaslevesque
I see what you mean. I was wrong, and thank you for teaching me better how delegates work in C#

[thomaslevesque]

What is this proposal attempting to achieve? Why would it be beneficial to change how the variable is captured and how would it differ from how the capture works today?

Well, for one thing it would be more efficient (accessing a constant is faster than accessing a field). It also changes the semantic of the capture, in that the value in the lambda is an independent copy of the captured variable, which is often desirable (e.g. in a loop, no need to explicitly make a local copy of the loop variable). It also makes things simpler for code that works on expression trees.

The specific use case that prompted this proposal was that in EF Core, the FreeText method only accepts a constant as the language argument (see dotnet/efcore#13315). In other words, you can't do this:

int lcid = CultureInfo.CurrentCulture.LCID;
var results = await _dbContext.Items
    .Where(i => EF.Functions.FreeText(i.Text, searchTerm, lcid))
    .ToListAsync();

because lcid in the lambda is actually <closure variable>.lcid, which isn't supported in the EF Core translator. Of course, this problem should be fixed in EF Core itself rather than in the language, but having the ability to explicitly capture the value of lcid would have provided a simple workaround.

[YairHalberstadt]

So () => valueof(foo) is essentially a shorthand for

var temp = foo;
() => temp;

[HaloFour]

@thomaslevesque

The variable still has to be hoisted into a field on a class instance. There isn't another mechanism through which the compiler can capture data into a delegate instance. You're really just changing when that field is assigned as it would then be a copy of the local (which may or may not be hoisted itself). foo can never be a constant in normal lambdas.

The difference is more apparent with expressions since you're asking the compiler to embed the current value of foo in a ConstantExpression. But that would be a difference in behavior that doesn't make much sense. And, as you mentioned, this is to gloss over a limitation of EF, which it sounds like EF should address, not the compiler. Other than static delegates the team has expressed no interest in pursuing capture lists like C++ supports them.

[thomaslevesque]

So () => valueof(foo) is essentially a shorthand for

var temp = foo;
() => temp;

Semantically, yes, but technically the actual code of the lambda would be different

[thomaslevesque]

The variable still has to be hoisted into a field on a class instance. There isn't another mechanism through which the compiler can capture data into a delegate instance. You're really just changing when that field is assigned as it would then be a copy of the local (which may or may not be hoisted itself). foo can never be a constant in normal lambdas.

Ah, I see what you mean. Yes, the value would still be a field on the closure type, it wouldn't really be a constant.

[ufcpp]

#163

[scalablecory]

This may have some benefits for multi-threaded code by reducing sharing.

[theunrepentantgeek]

e.g. in a loop, no need to explicitly make a local copy of the loop variable

Small nitpick. This behaviour changed in C# 5 (released 2012): A lambda within a foreach loop now captures the current value of the loop variable only; it's as though each iteration of the loop gets a new variable declaration.

This is one of the very few times they've made a breaking change to the language.

See Closing over the loop variable considered harmful, and Closing over the loop variable, part two by Eric Lippert for more details; they're the most authoritative sources I could find quickly.

[thomaslevesque]

@theunrepentantgeek yes, I'm aware of this. But there are other scenarios (e.g. for loops) where this can be useful.

[juliusfriedman]

Another way of possibly the same same...

Make a Lamba type such can be replaced out or leveraged similar to how to do for parallel, then just pass the spec defined options as the default and a user can change at a whim.

Overall I think we already do this for local functions. I.e. a struct is used rather than a class.

Would be trivial to add an attribute and options for further enhancement.

Then finally the short hand which can be extrapolated from c++ and molded into its appropriate place in c#, [] ....

[thomaslevesque]

This proposal never attracted much interest, and is of limited value, so it probably won't happen. Closing to reduce the clutter.

[CyrusNajmabadi]

Reactivating and moving to discussion. :)

[darrylmelander]

This is something that's always felt a little broken to me. Capturing value types by reference has never been the most intuitive behavior. This is the whole reason lambdas in a loop were written incorrectly so often that they first added a warning for it and then changed the behavior of for loops. It was never a misunderstanding of for loop variables, it was unintuitive capture behavior. I get why the language designers didn't want to introduce a bunch of rules about when to capture by value and when to capture by reference, but IMHO there really ought to be a way to capture by value without resorting to the current hackish workaround.

[TahirAhmadov]

This makes sense for LINQ expression trees, actually: many times a developer who uses a LINQ provider, be it EF or anything else, needs to pass in a ConstantExpression, and cannot modify the LINQ provider (the ORM) for whatever reason.

Regarding delegates, I think Roslyn can be improved to detect and optimize read-only captured locals, together with related work with optimizing locals capturing in general, like something I proposed in #6287. But valueof isn't needed in this case, because the compiler can determine how a captured local is used inside a delegate.

[sgf]

I propose to directly introduce new symbols, thereby changing the behavior, so that there is no much intrusive modification.

such as: "->"
()->a+b
that's will got the value a and b

[sgf]

The -> operator already exists in C# for dereferencing pointers. That is the reason the language uses => for lambdas instead of ->.

The use of -> is very limited AT now.

[CyrusNajmabadi]

This would be instantly ambiguous. Is a->b a pointer dereference, or a lambda?

[HaloFour]

Already legal syntax:

public struct Foo {
    public int X;
}

public unsafe class C {
    
    Foo* foo;
    
    public void M(int X) {
        var x = (foo) -> X;
    }
}

[sgf]

Already legal syntax:

public struct Foo {
    public int X;
}

public unsafe class C {
    
    Foo* foo;
    
    public void M(int X) {
        var x = (foo) -> X;
    }
}

did u can define var x = (foo) => X; at there place ?soo,what problem do u worry about.

[CyrusNajmabadi]

The problem is that it is syntactically ambiguous. When parsing we would treat this as a pointer dereference.

[NoctemCat]

I think a keyword, similar to "static" lambdas, that will indicate a capture by value would be nice