Why must conditional local functions be static?

[colejohnson66]

To conditionally compile an invocation of a function, we can tag it with the [Conditional(...)] attribute. These functions can be static or not, and it'll work. However, if the function is "local", it must be static. Why?

public static void Main()
{
    ConditionalFunction();

    // must be static
    [Conditional("DEBUG")]
    static void ConditionalFunction() =>
        Console.WriteLine("Debug!");
}

public static void Main() =>
    ConditionalFunction();
// does not need to be static (it is here as `Main` is static)
[Conditional("DEBUG")]
static void ConditionalFunction() =>
    Console.WriteLine("Debug!");

Without static on the local function form, I get the following error:

error CS8783: Local function 'ConditionalFunction()' must be 'static' in order to use the Conditional attribute

Why? Local functions are lowered to normal ones, just with unspeakable names. In this case, that's <Main>g__ConditionalFunction|0_0. And once they're no longer local, they're no different from normal functions that can be conditional. What's the reasoning for this discrepancy?

[HaloFour]

I want to say that it's probably more related to preventing capturing, which static local functions are not permitted to do. I don't know why that would be different for local functions defined in instance methods vs. static methods, other than maybe that the concern was implicitly capturing this?

[HaloFour]

See: https://github.com/dotnet/csharplang/blob/main/proposals/csharp-9.0/local-function-attributes.md#attributes
And: #4193

And: #1888 (comment)

Conditional local functions were only considered late in the development in the feature, and for expediency we decided to come up with a simple/coarse rule which could be potentially relaxed later.

If we were to relax this, I think we'd want to consider:

1. Can we allow usages which just read variables from the enclosing scope?
2. Can we allow variable writes, but somehow avoid transitioning variables from unassigned to definitely assigned when the local function is conditional?

[colejohnson66]

Ah. So it has to do with potential capturing/modifying of variables. That would make sense. Maybe it could be relaxed so that we can capture (but not modify) locals (idea one in that list)? I think that would be a nice middle-ground.

As far as modifying (mutating, not reassigning) locals, that's already possible with conditional functions. For example, I can pass a list into a conditional and modify it:

public void Test() {
    List<int> list = new() { 1, 2, 3, 4 };
    Evil(list);

    [Conditional("DEBUG")]
    static void Evil(List<int> list) =>
        list.Clear();
}

public void Test()
{
    List<int> list = new List<int>();
    list.Add(1);
    list.Add(2);
    list.Add(3);
    list.Add(4);
    List<int> list2 = list;
    <Test>g__Evil|0_0(list2);
}

[NullableContext(1)]
[CompilerGenerated]
[Conditional("DEBUG")]
internal static void <Test>g__Evil|0_0(List<int> list)
{
    list.Clear();
}

Allowing a capture of list, even if it can't be reassigned, would at least be a nice QOL improvement.

Is this something the team is willing to explore? Also, what's wrong with capturing this? A conditional instance function already holds a reference to this, but that's allowed.

[HaloFour]

As far as modifying (mutating, not reassigning) locals, that's already possible with conditional functions.

That is explicitly passed as a parameter. You could even use a ref parameter there to explicitly reassign the local, not just mutate it. But the concern is more over captures, not mutation, especially as captures with local functions have further impact to definite assignment, etc.

It sounds like it'd be possible to relax, it would just take some effort and enough of a reason to. I'm not on the team, tho, so I can't really comment as to whether it would be something they would take up, but they didn't appear to have ruled that out based on that earlier comment.

[RikkiGibson]

The nature of the analysis we need here is actually not that different from conditional method calls whose arguments are performing assignments. SharpLab.

int x;
ConditionalMethod(x = 1);
Console.Write(x); // error if ConditionalMethod call will be elided

versus with a local function:

int x;
conditionalLocalFunction();
Console.Write(x); // error if conditionalLocalFunction call will be elided

[Conditional(...)]
void conditionalLocalFunction()
{
    x = 1;
}

We actually already know which variables are definitely assigned by a local function, even indirectly through other local functions. The compiler's analysis can determine if the call will be elided or not in the compilation, and if it is, then after analyzing the call it basically just resets to the state from before the call, as if the call wasn't there.

It's possible that simply disabling the error which is reported for non-static conditional local functions will make the desired behavior "just work". If we verify that, we can certainly make the argument that it is a low-effort "feature". Although, more testing will certainly be needed in any case.

We will also need to more formally propose the change to LDM, and LDM would need to accept the proposal, before we could merge the change in the compiler.