Attribute-like Extensions

[0x0737]

Attribute-like Extensions

This is a modified version of the syntax posted originally here

The idea is to take hybrid approach and support both member and type-based extensions.
Basically, the type-based form will be the member form with grouping applied.
All old-style extensions have a corresponding new form.

Ungrouped extensions

"extension" pseudo-attribute

extension<...>(...) where ...

An ungrouped extension is denoted with an "extension" pseudo-attribute which precedes a member and succeeds all of its attributes.
It should be placed on its own line (though this is not mandatory).
An extension clause can have a "where" clause attached.

This version of proposal does use the attribute brackets syntax, though maybe this is not required. "extension" obviously is a keyword, not an attribute and should be highlighted as a keyword.

Let's look at methods first. Methods are special in the sense that there is already a form of instance extension methods in the language and they are the only members which can have generics declared.

Instance methods

Extension member lookup consists of two stages.
Firstly, all extension members eligible for the target type are determined.
Then, the correct overload is selected.

A full "extension" clause for instance method specifies the generic parameters which participate in the first lookup stage of the extension member and the underlying type and optionally, this-parameter passing modifiers and its name.
Specifying this-parameter name is only allowed in types marked with [CompatibleExtension] attribute.

extension<T1, T2>(ref readonly ExtendedType<T1, T2> param)
public void Method<T3, T4>()

You can think of ext-clause generic parameters as "parameters used in underlying type".

Specifying parameter name makes the method resemble an old-style extension and immediately compatible with already existing code.

But if you omit the name, this-parameter turns into a receiver, which allows the method body to directly reference its members, just as if they were declared in the extension type.

extension<T1, T2>(ref readonly ExtendedType<T1, T2>)
public void Method<T3, T4>()

In [CompatibleExtension] types you can mark the method with a [ThisName(name)] attribute while omitting this-parameter name after the underlying type if you wish to switch to the receiver syntax in the body while maintaining source and binary compatibility with existing code.

[ThisName("thisparam")]
extension<T1, T2>(ref readonly ExtendedType<T1, T2>)
public void Method<T3, T4>()

Instance generic call source-level compatibility

At a call site, parameters from the "extension" clause are already known for instance extension members, since the target type is already constructed.

If all method-decl parameters can be inferred from arguments, they can be completely omitted.

If some method-decl parameters can't be inferred from arguments, then:

1. If the instance extension method does not have a named this-parameter, only parameters from the extension clause must and can be specified.
2. If the instance extension method has a named this-parameter, either all parameters must be specified or a special syntax used to omit them:
   obj.A<.., object>()
   for the reasons, see Appendix 1

Inserting extension-clause generic parameters after method-decl ones

If for some reason you got an old-style extension which doesn't have the underlying type generic parameters placed first, you can explicitly specify the order of all parameters. If you mention at least one of the extension-clause ones, you must specify them all.

extension<A, B>(Dictionary<A, B>)
public void ExtMethod<B, C, A>(C arg)

Other instance members

Extensions of other member kinds do not support named this-parameters.

extension(ExtendedType)
public int Property => 0;

Static members

A full "extension" clause for static member specifies the generic parameters which participate in the first lookup stage of the extension member and the underlying type.

extension<T1, T2>(ref readonly ExtendedType<T1, T2>)
public void Method<T3, T4>()

For static extension members generic parameters are filled like so: ExtendedType<T1, T2>.Method<T3, T4>(ref arg). The first two type parameters here are declared in the "extension" clause wherever the method itself lies.
Parameters from the method declaration are specified by the caller or inferred from the arguments.
If all method-decl parameters can be inferred from arguments, they can be omitted.

Examples for ungrouped extensions

The examples below will show the new syntax for methods and other member kinds in action.

[CompatibleExtension] // this allows to declare instance extension methods with named this-parameters
public extension ExtensionA
{
    // T goes into "extension" clause because it is used in the underlying type
    // This extension is backwards-compatible because it has a named this-parameter
    extension<T>(List<T> list) where T : class?
    public void ExtMethod0(int someArg)
    {
        // "list" is a this-parameter now.
        // You can access its members only by referring to them like 'list.Member'
    }

    [ThisName("thisparam")]
    extension<T>(List<T>) where T : class?
    public void ExtMethod1(int someArg)
    {
        // "thisparam" is a this-parameter now.
        // You can access its members only by referring to them like 'thisparam.Member'
    }

    // Generic parameters not used in the receiver type are specified in the method declaration.
    [ThisName("thisparam")]
    extension<T>(List<T>) where T : class?
    public void ExtMethod2<U>(T someArg1, U someArg) where U : struct
    {
        // "thisparam" is a this-parameter now.
        // You can access its members only by referring to them like 'thisparam.Member'
    }

    extension<T>(List<T>) where T : class?
    public void ExtMethod2_New<U>(T someArg1, U someArg) where U : struct
    {
        // "this" is the receiver now. 
        // You can access its members by referring to them like 'this.Member' OR
        // just 'Member' like if they were declared right here in the extension
    }

    // This is how you include receiver modifiers in an "extension" clause.
    // It doesn't matter whether it's a named this-parameter or a receiver
    extension<T>([SomeAttribute] ref T) where T : struct
    public void ExtMethod3(T val)
    {
        // "this" is the receiver now. It is passed by-ref and has [SomeAttribute]
        // You can access its members by referring to them like 'this.Member' OR
        // just 'Member' like if they were declared right here in the extension
        this = val;
    }

    // This is how you declare instance extension properties
    // You can't have named this-parameter here.
    extension<T>(T) where T : class?
    public int ExtProperty => 1;

    // And indexers (why they still can't named?)
    // Although we have parameters here, let's not complicate further and only use receivers.
    extension<T>(T) where T : class?
    public object this[int i]?
    {
        get ... set ...
    }

    // And static methods
    extension<T>(T) where T : class?
    public static T StaticExtMethod()
    {
        return ...
    }

    // And operators
    extension<T>(T) where T : class?
    public static explicit operator int(T obj)
    {
        return obj.GetHashCode();
    }

    // You got the idea
}

How to call these?

List<object> list = new();
int arg = 0;

// 0
list.ExtMethod0(arg);

// 1
list.ExtMethod1(arg);

// 2
list.ExtMethod2<object, int>(new object(), arg);
list.ExtMethod2<.., int>(new object(), arg);

// 2_New
list.ExtMethod2_New<int>(new object(), arg);

// 3
arg.ExtMethod3(1);

// Instance Property
_ = list.ExtProperty;

// Instance Indexer
_ = list[0];

// Static methods
_ = object.StaticExtMethod();

// Operator
_ = (int)(new object());

How to call these like static members on the extension type?

When you call new extension methods like static ones,
they appear to you like old ones. The extension-clause parameters are joined with the method parameters.

// 0
ExtensionA.ExtMethod1(list, arg);

// 1
ExtensionA.ExtMethod1(list, arg);

// 2
// Since this method requires additional parameter which cannot be inferred, you have to fill in generics explicitly.
ExtensionA.ExtMethod2<int, int>(list, new object(), arg);

// 2_New
// Support for this is not mandatory, it is incompatible anyway
ExtensionA.ExtMethod2_New<int, int>(list, new object(), arg);

// 3
ExtensionA.ExtMethod3(ref arg, 1);

// The other member kinds don't require compatibility with old extensions.
// They still can be lowered to static members of the extension type.

Now, let's convert that extension to multiple type-based ones, which will be identical to previous

public extension<T>(List<T>) ExtensionA where T : class?

The "extension" clause has moved to the extension type declaration and got merged with it. Its "where" clause is now attached like method's.
Why parameters for the underlying type are still specified in the "extension" clause?
Because we need to be able to do old-style calls of static methods on the extension type and still have the benefit of not repeating the underlying type in the extension members:

ExtensionA.ExtMethod1(receiver, arg) vs ExtensionA<int>.ExtMethod1(receiver, arg)

But we don't have generic extension types in C#? Well, now we will, so this is required to have compatibility and to preserve extension syntax uniformity.

public extension<T>(List<T>) ExtensionA where T : class?
{
    extension(list)
    public void ExtMethod0(int someArg)
    {
        // "list" is a parameter now.
        // You can access its members only by referring to them like 'list.Member'
    }

    [ThisName("thisparam")]
    extension
    public void ExtMethod1(int someArg)
    {
        // "thisparam" is a parameter now.
        // You can access its members only by referring to them like 'thisparam.Member'
    }

    [ThisName("thisparam")]
    extension
    public void ExtMethod2<U>(T someArg1, U someArg) where U : struct
    {
        // "thisparam" is a parameter now.
        // You can access its members only by referring to them like 'thisparam.Member'
    }

    extension
    public void ExtMethod2_New<U>(T someArg1, U someArg) where U : struct
    {
        // "this" is the receiver now. 
        // You can access its members by referring to them like 'this.Member' OR
        // just 'Member' like if they were declared right here in the extension
    }
}

public extension<T>(T) ExtensionB where T : struct
{
    extension([SomeAttribute] ref this)
    public void ExtMethod3(T val)
    {
        // "this" is the receiver now. It is passed by-ref and has [SomeAttribute]
        // You can access its members by referring to them like 'this.Member' OR
        // just 'Member' like if they were declared right here in the extension
        this = val;
    }
}

public extension<T>(T) ExtensionC where T : class?
{
    extension
    public int ExtProperty => 1;

    extension
    public object this[int i]
    {
        get ... set ...
    }

    extension
    public static T StaticExtMethod()
    {
        return ...
    }

    extension
    public static explicit operator int(T obj)
    {
        return obj.GetHashCode();
    }
}

Multiple 'extension' scopes in an extension

Multiple extension scopes can be specified in an extension type to include extensions for different types. An extension clause on an extension type, as shown in the former example, also denotes an extension scope, but merged with the type declaration. extension scopes can't be nested and they can't include parameter modifiers or this-parameter name. These properties belong to extension clauses of each individual member.

public extension ExtensionA
{
    extension<T>(List<T>) where T : class?
    {
        extension(list)
        public void ExtMethod0(int someArg)
        {
        }

        [ThisName("thisparam")]
        extension
        public void ExtMethod1(int someArg)
        {
        }

        [ThisName("thisparam")]
        extension
        public void ExtMethod2<U>(T someArg1, U someArg)
        {
        }

        extension
        public void ExtMethod2_New<U>(T someArg1, U someArg)
        {
        }
    }
    
    extension<T>(T) where T : struct
    {
        extension([SomeAttribute] ref this)
        public void ExtMethod3(T val)
        {
            this = val;
        }
    }

    extension<T>(T) where T : class?
    {
        extension
        public int ExtProperty => 1;

        extension
        public object this[int i]
        {
            get ... set ...
        }

        extension
        public static T StaticExtMethod()
        {
            return ...
        }

        extension
        public static explicit operator int(T obj)
        {
            return obj.GetHashCode();
        }
    }
}

Examples

1.

public partial extension<TSource>(IEnumerable<TSource>) Enumerable
{
    extension(source)
    public IEnumerable<IGrouping<TKey, TElement>> GroupBy<TKey, TElement>(
        Func<TSource, TKey> keySelector,
        Func<TSource, TElement> elementSelector) => ...;
}

lowers to

public static partial class Enumerable
{
    public static IEnumerable<IGrouping<TKey, TElement>> GroupBy<TSource, TKey, TElement>(
        IEnumerable<TSource> source,
        Func<TSource, TKey> keySelector,
        Func<TSource, TElement> elementSelector) => ...;
}

2.

public partial extension MemoryExtensions
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    extension<T>(T[]? array)
    public Span<T> AsSpan(int start, int length)
    {
        return new Span<T>(array, start, length);
    }
}

lowers to

public static partial class MemoryExtensions
{
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    public static Span<T> AsSpan<T>(T[]? array, int start, int length)
    {
        return new Span<T>(array, start, length);
    }
}

Appendix 1 (Generic parameters in instance syntax)

There is a problem when it comes to the instance syntax for methods.
With old-style extensions the only way you can specify type arguments in
instance calls is to specify all of them or none. But in the context of this
"proposal" you can only specify those which are directly declared on the method.
And here that problem arises.
We have to support the old syntax where you specify all arguments too.
But if we were to support both ways, adding a new method with the same signature besides a different number of generic parameters would become a breaking change.

Suppose we have a call obj.A<object>()

And extension:

extension<T>(T)
public void A()

If we add a new extension

extension<T>(T)
public void A<U>()

obj.A<object>() should mean the same A with no method-decl params. So, parameters from the extension clause could have priority over method-decl ones.

But if we had that extension initially

extension<T>(T)
public void A<U>()

obj.A<object>() would mean the A with one method-decl param.

So adding

extension<T>(T)
public void A()

becomes a breaking change, as obj.A<object>() now calls the A with no method-decl params.

One way we can make it is to remove the ability to do instance calls without filling extension-clause generic params and require something explicit like obj.A<.., object>() if we want to do an instance extension call with generics filled partially. ".." would mean "automatically fill in all extension-clause generic parameters"
This way we kind of preserve the benefit of split generics.
In the current version of the proposal this policy only applies to extension methods with named this parameters.

[HaloFour]

Why the use of square brackets? Given it requires completely new syntax which won't be compatible with attributes, and it won't be implemented via attributes, why try to borrow elements of attribute syntax? I feel the following conveys everything already:

extension<T1, T2>(ref readonly ExtendedType<T1, T2> param)
public void Method<T3, T4>()

[0x0737]

I feel the same, but decided to include them because the inner "where" clause theorethecally may cause parsing problems. If this is not the case, I'll remove them.

Also there is a question regarding the explicit use of "this" in cases where you already have underlying type defined in the parent scope.
Currently it is not required to write

extension(ref this)

but I feel like maybe it should be? Or maybe it should be always required?

[0x0737]

Removed square brackets & tweaked modifiers for grouped syntax. Now uses "this" for instance extensions in place of type name if modifiers are specified.