Is it intentional for extension methods to not be allowed as top-level functions?

[IanKemp]

Prompted by this Stack Overflow question: https://stackoverflow.com/q/66581096/70345 (please read the answers for additional context/speculation).

The tl;dr is that Roslyn does not allow defining extension methods as top-level functions. The relevant spec does not appear to define any special behaviour around top-level functions that would preclude them from being extension methods, however the extension methods spec states that:

Extension methods can only be declared in non-generic, non-nested static classes.

Since a top-level function is not technically defined in a class, even though it's compiled to a method inside a static Program class, is the required declaration of extension methods in a static class the overriding factor here? In other words, does the extension methods spec have "higher precedence" than the top-level statements one, and/or is there language missing from one or both of these specs regarding their potential for interplay?

Alternatively, should Roslyn be allowing extension methods as top-level functions, i.e. is there a bug in Roslyn's implementation of the top-level statements spec?

[Joe4evr]

Yes. (emphasis mine):

Within member declarations in a compilation unit or namespace body that contains a using_static_directive, the accessible nested types and static members (except extension methods) contained directly in the declaration of the given type can be referenced directly.
[...]
A using_static_directive specifically does not import extension methods directly as static methods, but makes them available for extension method invocation.

[canton7]

Is using static relevant here?

[HaloFour]

IIRC top-level functions are really just local functions declared within the implicit Main method, and local functions can't be extension methods.

[connellsharp]

I'm beginning to think this is the correct way to think about it. In two steps:

1. Top-level functions are converted to local functions within the Main method.
2. Those local functions are then lifted into the Program class, as part of the normal implementation of local functions.

So these "top-level methods" should be thought of as local functions when developing, and the same restrictions apply. E.g. you can't declare local extension methods.

If top-level extension methods were to be included in the language in future, it feels like it would make sense to do it as part of a more general feature that allows local extension methods. Which would mean top-level extensions are inaccessible from outside of Program.Main.

[333fred]

This is exactly the correct way to think about them. Top-level statements (including top-level function declarations) are wrapped in an implicit Main method. What happens after that is the standard way methods are compiled, including local functions inside a method.

[IanKemp]

I'm still confused. Given the following class declaration (which is essentially the same as the top-level statements we've been discussing):

static class Program
{
    public static void Main()
    {
        static int ToInt(this string numberString) => int.Parse(numberString);
        
        "42".ToInt();
    }
}

I would (based on my understanding of how local functions are lifted into class methods) expect Roslyn to resolve it to the following:

static class Program
{
    static int ToInt(this string numberString) => int.Parse(numberString);
    
    public static void Main()
    {
        "42".ToInt();
    }
}

And indeed, if I paste the latter program into SharpLab, it compiles as expected:

[Extension]
internal static class Program
{
    [Extension]
    private static int ToInt(string numberString)
    {
        return int.Parse(numberString);
    }

    public static void Main()
    {
        ToInt("42");
    }
}

So why doesn't the first one?

[HaloFour]

How they are lowered is an implementation detail and as with normal local functions it will change depending on what else you do in the method. The compiler doesn't consider those implementation details when it considers whether or not a local function is eligible to be considered as an extension method. Same as how local functions don't participate with overloads of instance members in the same class.

[canton7]

The compiler doesn't consider those implementation details when it considers whether or not a local function is eligible to be considered as an extension method

(I made that abundantly clear in my StackOverflow answer to this question).

Extension methods are specified as only being valid when declared in static (non-generic, non-nested) classes. The spec says this. It doesn't matter what the compiler does afterwards, what matters is how it's declared. The fact that the compiler ends up lifting top-level methods into a generated class is completely irrelevant.

Yes, the spec could be changed, but right now the compiler will only accept an extension method if it's declared in a static class.