Proposal: Use static keyword for lambdas to disallow capturing locals and parameters (VS 16.8, .NET 5)

[mattwar]

Allow Func<int, string> = static i => i.ToString();.

• Proposal added (here)
• Discussed in LDM 2019-10-21
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

---

To avoid accidentally capturing any local state when supplying lambda functions for method arguments, prefix the lambda declaration with the static keyword. This makes the lambda function just like a static method, no capturing locals and no access to this or base.

int y = 10;
someMethod(x => x + y); // captures 'y', causing unintended allocation.

with this proposal you could the static keyword to make this an error.

int y = 10;
someMethod(static x => x + y); // error!

const int y = 10;
someMethod(static x => x + y); // okay :-)

LDM history:

• 10/21/2019

[mattwar]

Related issues/proposals:
Lambda Capture lists: dotnet/roslyn#117
Non-Capture Lambdas with ==> syntax: dotnet/roslyn#11620

[alrz]

I'd really prefer capture lists overs this, that'd be something like this []() => {}. what advantages we'd have over capture lists?

[mattwar]

@alzr just considering an alternative to capture lists in case we chose not to do capture lists.

[MgSam]

I like this better than capture lists, which I think are way too heavyweight.

[DavidArno]

I don't see the point to this, but it's got a bunch of up-votes. So rather than just down-vote, I'll assume I'm ignorant of the issue. Why is this (and/or capture lists) needed? Is accidental closure capture a problem for people?

[iam3yal]

@MgSam Too heavyweight for whom? people want to have control over what gets captured and sometimes how it gets captured and this locks the language into a specific behaviour which seems too limited.

People can always have this as a syntactic sugar to capture lists but doing this first would be a shame.

I have a bad feeling about capture lists, they won't make it. 😆

[jnm2]

I'm in the same place as @DavidArno. If there is a special case where you need to disrupt the syntax to be absolutely sure that you aren't capturing anything, is it so bad to refactor it to a static method?

[yaakov-h]

Does this need to be a language feature or is this something you could reasonably achieve with an Analyzer?

[alrz]

As another alternative: https://github.com/dotnet/roslyn/issues/6671 (see the example).

[MgSam]

@eyalsk

people want to have control over what gets captured and sometimes how it gets captured and this locks the language into a specific behaviour which seems too limited.

"People" is kind of vague and arbitrary, no? I've never had a need for such a feature and even here among C# enthusiasts demand seems tepid at best. While on the other hand there have occasionally been times when I want to ensure that a lambda (or now a local function!) is not closing over anything.

Lambda capture lists add a bunch of new syntax for a narrow use case. And you'll undoubtedly have some programmers overuse them every single time they write a lambda, needlessly complicating code. Whereas this proposal reuses an existing keyword in a lightweight, thoughtful, and natural way.

Plus, anytime a feature suggestion is ripped straight from C++, I'm immediately suspicious. :P

[DavidArno]

@MgSam,

While on the other hand there have occasionally been times when I want to ensure that a lambda (or now a local function!) is not closing over anything.

This is what I'm not getting here. If I "want to ensure that a lambda (or now a local function!) is not closing over anything" then I make it a private method. The only reason I see for creating local functions is because I want to close over something. And regarding lambdas, again I'm struggling to see how I'd "accidentally" create a closure and - even if I did - unless I make a habit of cluttering my lambdas with eg the static keyword, I'd still end up making that mistake.

If we didn't yet have lambdas, then there could be a case for them not allowing closures by default, but this proposal seems a classic case of swinging the stable doors shut as the horse disappears over the horizon...

[MgSam]

@DavidArno
You seem to be arguing two contradictory things:

• Lambdas / local functions are useless without the ability to capture something.
• Lambdas should have been designed as non-capturing by default. (and by point 1 of your argument, would have therefore been useless)

If I "want to ensure that a lambda (or now a local function!) is not closing over anything" then I make it a private method.

I very highly doubt that you do this. The vast majority of the time when you are using LINQ, you are probably not calling private methods with it, but rather creating lambdas.

It is true that for a chain of LINQ methods prefixing them all with static would be tiresome and noisy. Perhaps that's a reason for instead taking an attribute based approach to this that can either be applied locally to a given lambda or to an entire method / class to ensure no captures anywhere.