Champion "static local functions" (16.3, Core 3)

[jcouv]

The proposal is to declare a local function as non-capturing. The keyword to indicate that would be static.

Note: if we do this, then we should also consider allowing parameters and locals of the local function to shadow parameters and locals from the containing method.

• Proposal added
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

Related discussion thread, including a discussion of "capture lists" (a more elaborate feature): #1277

Note: EE scenarios are a concern.

Do we want to allow some other modifiers (like unsafe)?

LDM history:

• https://github.com/dotnet/csharplang/blob/master/meetings/2018/LDM-2018-09-10.md
• https://github.com/dotnet/csharplang/blob/master/meetings/2019/LDM-2019-01-16.md (shadowing in lambdas)

[bondsbw]

To be clear, would this fit @benaadams's definition of static?

A static method in a class hides its enclosing scope; you can't access and of its instance data or call any of its instance methods - only call static functions and access static data.

Likewise a static local function shouldn't have access the the parent functions local state or the classes instance state, much like a regular static function.

The static local function is providing scoping so as not to pollute the class with a static function which is only called in a single method.

[jcouv]

@bondsbw Yes, that's what I'd have in mind. The local function would not be able to access variables from parent method or instance fields. It could only access variables that it declares (parameters or locals) and static fields.

[HaloFour]

Is there a big reason to do this for local functions, aside avoiding accidental mutations? Aren't local functions significantly more efficient with captures?

[jcouv]

@HaloFour The primary motivation for this proposal is readability/maintainability. Knowing that some code is isolated makes it easier to understand, review and re-use. That's the same general argument as with any kind of isolation like object encapsulation or functional programming.

There is also a practical motivation. There are good reasons why parameters or locals of local functions should not shadow variables from the enclosing scope. But in practice, there are many pieces of pure logic that make sense to extract as local function, but where this restriction becomes inconvenient (prevents you from using obvious variable names).
Having static local functions and additionally allowing static local functions to declare their own variables regardless of context solves that problem (while avoiding the pitfalls of shadowing).

[popcatalin81]

What’s the Benefit over a private static function? Local functions benefit is exactly capturing

[orthoxerox]

@popcatalin81 more fine-grained access control, primarily

[mgravell]

@HaloFour it isn't just mutations; it is also to incredibly useful to avoid accidentally creating the capture machinery, especially in hot paths. This can have a surprising amount of overhead, especially in scenarios like async. Again, on hot paths, a common pattern in some async pipes is to try to avoid the async machinery completely if it will often be synchronous, falling back into an async completion if it turns out to be incomplete - which means all the local state (including the capture machinery) is going to end up on the heap (because of how await works when tasks are incomplete); doing this manually can have significant savings for performance critical code, and it turns out that local functions as long as you don't capture are a very tidy way of doing it

@popcatalin81 scoping and expressiveness. I actually strongly disagree with you that the benefit of local functions is "exactly capturing" - I've written plenty of local functions, and the ones that make use of capture are by far the minority. Well, let me rephrase: the ones where I intentionally used capture are the minority. But yes, functionally they're just like regular private static methods; in fact, my usual "did I capture without realising it?" check is exactly to move the local function out of the method (so: a private static), see if the code still compiles, then move it back (and remove the modifiers).

[HaloFour]

@mgravell

If the goal is to avoid creating async machinery for capturing then I don't see why it would be limited to avoiding capture on local functions where said machinery requires significantly less overhead.

And, like most proposals that involve limiting functionality/syntax for the purpose of improving code generation and performance, why is this not suitably managed by an analyzer? Most people will not care about this degree of optimization.

I've never reached for a local function unless I wanted to capture. I see zero point to them otherwise.

[HaloFour]

@jcouv

Knowing that some code is isolated makes it easier to understand, review and re-use.
Having static local functions and additionally allowing static local functions to declare their own variables regardless of context solves that problem (while avoiding the pitfalls of shadowing).

IMO, those two statements are in direct contradiction. Allowing a local function to shadow variables would negatively impact the readability of said function. Now anytime you see a local function you have to double-back to the signature to see what that identifier refers to.

[jcouv]

@HaloFour Any design involves some trade-offs and tensions. I recognize it is a fair concern to discuss and experiment with.
From experience with static methods, I've found them to reduce the cognitive load rather than increase it, despite their introducing a "mode". When reading a static local function with variables defined independently of the parent scope, I suspect the same modality will kick in so it won't be confusing.

[HaloFour]

@jcouv

Any design involves some trade-offs and tensions. I recognize it is a fair concern to discuss and experiment with.

I agree. Consider this just part of that discussion. 😁 Despite my arguments I'm fairly ambivalent about the proposal.

Where this feature tries to address performance of certain aspects of generated code, particularly around async method machinery, it feels like this could be easily (and appropriately) addressed via analyzers. By itself this feature seems like it would barely scratch that surface. Local function capture, by itself, is not the performance problem. It's only in conjunction with those other features like async methods or delegates where the compiler resorts to the less efficient machinery. So why target a language change that barely scratches the actual problem?

I'm much more opposed to the notion of the shadowing. I agree that having to come up with a lot of different names for identifiers can be restrictive. The team was very quick to dismiss that argument in the context of leaky out declaration variables and pattern variables.

From experience with static methods, I've found them to reduce the cognitive load rather than increase it, despite their introducing a "mode".

Current static methods don't have to deal with other locals being potentially in scope, so I don't feel that this comparison is appropriate. The rules regarding shadowing fields don't change between instance or static methods.