[Proposal]: Extensions as static types

[MadsTorgersen]

Extensions as static types

This has been moved to https://github.com/dotnet/csharplang/blob/main/meetings/working-groups/extensions/extensions-as-static-types.md.

[BlinD-HuNTeR]

If we can live without those aspects of the extension feature, we can ship it faster

Please ship it already in C# 13!!! Or in the first preview of C# 14, if possible 🙂

[julealgon]

If we can live without those aspects of the extension feature, we can ship it faster and with less implementation complexity and risk. This does not prevent us from adding roles later, and in the process "upgrading" extensions to also be instance types. It allows us to further stratify the work across multiple waves of effort.

As long as it doesn't compromise future designs (which it doesn't see to, considering it can be "expanded" to non-static later), I'm all for this as well.

In a sense, this is similar to "sealed by default, open as needed" best practice. The sealed is an extra constraint that can be removed later, same as static in this context.

[333fred]

If we can live without those aspects of the extension feature, we can ship it faster

Please ship it already in C# 13!!! Or in the first preview of C# 14, if possible 🙂

Neither of those things are likely to happen.

[HaloFour]

My only question might be how this would play for helper methods. Could a private extension method be in scope within the extension that could be called from other extension members? e.g.:

public extension StringExtensions for string {
    public void M() {
        this.HelperMethod();
    }

    private void HelperMethod() { }
}

or would you be expected to declare that helper method as a static method, like we do with extension methods today?

public extension StringExtensions for string {
    public void M() {
        HelperMethod(this);
    }

    private static void HelperMethod(string value) { }
}

The former would be nice...

[TahirAhmadov]

I I'm not sure why the prohibition of:

Disallow use of an extension as an instance type. Just like static classes this means that it cannot be the type of a value or variable, and cannot be a type parameter.

Necessitates the change to how this is treated. I think we can have our cake and eat it, too, in this case.

[333fred]

this is an instance variable. Definitionally, if the type of an instance variable cannot be an extension, then this cannot be that extension either.

[MgSam]

Regarding the disambiguation section- will it not be possible to do: E2.M("foo")? As in, if there are ambiguities today you can always fall back to calling the method on the static class manually. Why wouldn't/shouldn't that work in the new world too?

[TahirAhmadov]

this is an instance variable. Definitionally, if the type of an instance variable cannot be an extension, then this cannot be that extension either.

I'm not sure I understand the logic here. Let's imagine this is of the extension type for syntax purposes (leaving implementation/emit strategy aside for a second). Why can't we just prohibit using the extension type as a type of fields/locals/params/properties/etc. and call it a day? Would there be negative consequences of such a prohibition while keeping this "extension typed"?