[Proposal]: Permit extension methods in nested (static) classes

[albahari]

Summary

Remove the restriction that extension methods must be defined in top-level classes, allowing them to exist in nested classes.

class Outer
{
    string text = "hello".LocalExtension();

    public Outer()
    {
        Console.WriteLine ("test".LocalExtension());
    }

    static class Extensions
    {
        public static string LocalExtension (this string s) => ...
    }
}

Motivation

The primary use-case is scripting, as described here.

It would also be useful in restricting the scope of extension methods to a particular class.

Complexity and learning burden

I would argue that this does not make the language harder to learn or understand, because it merely removes a restriction that lacks an obvious cause.

Alternatives

In the scripting scenario, the alternative is for the scripting tool to identify classes that define one or extension methods, and then remove those classes from the implicit containing type, redefining them as top-level classes. This also requires adding a using static Script directive and registering code-fixes to promote the accessibility of any members of the outer class that are no longer accessible. The last step requires action from the end-user that's highly counterintuitive.

Unresolved questions

1. Should extension methods in nested types have a higher resolution precedence?
2. Should extension methods in nested types be accessible from outside the containing type if a using static Outer directive is present?

[CyrusNajmabadi]

The primary use-case is scripting, #8696 (comment).

While in general i don't view this request as something i'm in favor of, i do think the particular special case here warrants examination. In other words, i would do what is necessary to make extensions work in scripting. Vs a generalized solution to make them work for any nested class.

That's just me though, others on the LDM may feel better about this wider option.

[albahari]

I'm open to ideas on how else this could be accomplished without considerable complexity or breaking changes.

[dotlogix]

I second this proposal but for me the scoping is the far more important part. Being able to "private" create extensions for a single class especially in combination with source generation is a very useful option imho.

It also solves one of my recurring issues with ambiguity of similar extension methods. With public extension methods you always have clashes when you want to create an extension method with the same name, but different generic arguments or where conditions.

TLDR:
I think there are a lot of other examples which would be a lot easier if we could just create private extension methods in non-static or nested classes.

If you have more time to read here is an example from one of my projects.
I am currently writing an ECS which works similar to Bevy and heavily relies on source generation.

public class MoveSystem {
    public void Execute(Query<(PositionComponent position, VelocityComponent velocity)> query) {
        foreach(var entitiy in query) {
            entity.Position += entity.Velocity;
        }
    }
}

Behind the scenes I am creating a new ref struct for the QueryResult taking the tuple element names as fields names. Now I need a specialized enumerator for query returning this new struct. This can be done using an extension method which is also source generated.

public ref struct QueryResult {
   // ...
}

public ref struct QueryEnumerator {
   // ...
}

BUT:
These types are highly specialized and only useful for this specific system. You can easily create a GetEnumerator extension method for the specialized Query<..> returning this Enumerator.

However because Systems can't be static classes themselfs because of other C# constraints (Generic arguments can't be static classes) I have to move this GetEnumerator method to a separate class. This then requires QueryResult, QueryEnumerator to be at least internal as well.

These methods could then clash with different similar systems with slightly different names.
This could be easily solved by just creating the GetEnumerator extension method in the same or a nested class.
If would create these methods and logic myself I could work around it using file static classes but this is not possible to do with source generation.

[egvijayanand]

This would be great if implemented, as it would restrict the scope of those extension methods to the containing type.

With this, styling the UI controls with fluent APIs is relatively easy, with methods in the nested as local and in the top-level as global scope.