Anonymous delegate type

[kyoyama-kazusa]

This discussion topic aims to unify the rules on delegate type declarations of parameters and local variables.

A little problem

Today delegate type is a very good mechanism to operate with methods, but sometimes they are still not neat. Consider this example:

// Delegate type declaration
public delegate void ArrayInitializer<T>([NotNull] scoped ref T[]? array);

// Consume
public static void InitializeArray<T>(this T?[] array, ArrayInitializer<T> initializer)
{
    foreach (ref var element in array.AsSpan())
    {
        initializer(ref element);
    }
}

Here we have an extension method that can initialize an array via the specified method. However, the method cannot be valid until we define a real delegate type.

Sometimes it is not necessary to define a new type because it may only use once. In addition, it is not generalized because we may sometimes use a delegate type whose signature is same as this delegate type ArrayInitializer.

If we use function pointers like delegate*<ref T?, void>, it may partially solve the problem, but it still leaves something inconvenient:

• It cannot capture variables from caller
• It cannot specify scoped keyword
• It cannot apply attribute types such as NotNullAttribute to the parameter scoped ref T? variable

Due to solving this problem, I suggest C# provide a better way to use delegate types, especially for anonymous delegate types.

Syntax

I suggest use a nearly-same syntax as function pointers to create anonymous delegate types:

delegate<[NotNull] scoped ref T?, void>

Removing token * to describe it is an anonymous delegate type, differentiating with function pointers. The same rule with function pointers is, the last "type parameter" of anonymous delegate type declaration is the return type. If the method doesn't require a return type, void should be explicitly inserted into the last type parameter's position like delegate<void> equals to delegate void Action().

Different with function pointers, we can apply attribute types onto parameters and allow using scoped keyword, like the above example.

If compiler detects such syntax, it may create a new delegate type or re-use such type having created. The generated type may like this:

// generated
public delegate void <$AnonymousDelegateType>_0000001([NotNull] scoped ref T? arg1);

Another examples

// Sort method
public static void Sort<T>(T[] @this, delegate<scoped ref readonly T, scoped ref readonly T, int> comparer);

// For-each method that uses reference on each element
public static void ForEachRef<T>(this T[] @this, delegate<scoped ref T> callback);

// Create an `IEqualityComparer<T>` using specified methods
public static IEqualityComparer<T> Create<T>(
    delegate<scoped ref readonly T, scoped ref readonly T, bool> equals,
    delegate<[DisallowNull] scoped ref readonly T, int> getHashCode
);

// Declare default value
delegate<int = 42>

// Declare an alias
using ObjectInitializer = delegate<[System.Diagnotics.CodeAnalysis.NotNullAttribute] scoped ref object?>;

// Conditional and switch expressions
delegate<int> f = condition ? static () => 42 : () => capturedIntegerVariable;

// Attribute-matched variable declaration and its initializer
delegate<[NotNull] scoped ref T?, void> method = static ([NotNull] scoped ref T? variable) => variable = new();

// Complex declaration
// Note: '[return: AttributeType]' syntax may not be required
// because the return type is always declared at the last position.
delegate<scoped ref T, [return: AttributeType] scoped ref T>

Other considerations

Synthesized delegate types in API

C# compiler can determine which types are .NET APIs, and which are not. The rules can be simplified like this:

1. If an anonymous type requires a modifier like ref, scoped, params, it should be synthesized.
2. If an anonymous type uses attribute declaration, it should be synthesized.
3. If .NET contains such declarations without modifiers, can be found in Action and Func delegate types group, it shouldn't be synthesized.
4. Otherwise, it should be synthesized.

Complex type declaration

// Anonymous delegate type array
delegate<void>[]

// Pointer to anonymous delegate type
delegate<void>*[]

// Nullable delegate type
delegate<void>?[]

// Delegate type with type attribute
[type: A] delegate<void>
// or
[A] delegate<void>
// or
delegate[A]<void>

// A delegate type returning a 'delegate<void>', with attribute '[A]' equivalent to '[param: A]'
delegate<[A] delegate<void>>

// A delegate type returning a '[return: A] delegate<int>'
delegate<[return: A] delegate<int>>

// A delegate type returning a '[A] delegate<int>'
delegate<[type: A] delegate<void>>

// Another complex example
[return: A] delegate<[return: A] delegate<int>>

Generic delegate type

Because anonymous delegate types are applied to cases not as declarations, such delegate types may not require type parameters, which is different with real delegate type

delegate void ArrayInitializer<T>([NotNull] scoped ref T? value);

In using, we may not apply <T> in code so we may not support on this case.

//                                          <T> declaration may not appeared in code
public static void InitializeArray<T>(this T?[] array, delegate<[NotNull] scoped ref T?, void> initializer);
//                                                             ~

Type equivalent on delegate types (Predicate<T> vs. Func<T, bool>)

I prefer delegate<T, bool> to present Func<T, bool> instead of Predicate<T>. Just like the behavior with var method = Predicate<T>;.

Similar issues

• [Proposal]: Delegate Type Arguments Improvements #5321 (Delegate Type Arguments Improvements)
• Allow `out`, `in`, and `ref` in generic type parameters. #7839 (Allow out, in, and ref in generic type parameters)
• Proposal: Function pointers on instance methods #7331 (Function pointers on instance methods)

[HaloFour]

I don't see why it's onerous to declare a delegate type in these cases, especially since their signature is pretty different from a general purpose Action/Func delegate. Having a properly defined delegate type provides the vehicle for the appropriate documentation for how to use that delegate with the consuming method.

The generation of a delegate creates all sorts of additional problems, especially as it is a public name that has to remain consistent between recompilations otherwise it breaks binary compatibility. Thus any such generated naming convention needs to be baked directly into the ECMA/ISO specs. To me, that alone makes it not worth the effort.

[kyoyama-kazusa]

Hello.

In my opinion, delegate types is the only the best selection that can support both variable-capturing and operation-storages. I know that delegate types can be used in event handlers of course, but without them, we cannot do such things except creating a local function or a method, or allow an extra argument passing into the method to achieve this goal, increasing the complexity in code.

The big disadvantage of delegate types is that it is a real type, storing a method list instead of the one method that just like function pointers. In .NET APIs, many of methods use delegate types as parameters:

• string.Create<TState>(int length, TState state, SpanAction<char, TState> action)
• Enumerable.All<TSource>(this IEnumerable<TSource> source, Func<TSource, bool> predicate)
• List<T>.bool Exists(Predicate<T> match)
• List<T>.Sort(Comparison<T> comparison)

and so on. Such delegate types are declared without using its "method list" function, but "operation-storages" one. The delegate type like SpanAction<,> may not be created if we have this feature. We create them because we cannot use just Action<> and Func<> because ref struct types cannot be used in typ arguments.

C# 13 have a new feature that allows ref struct types as type arguments by use type constraint where T : allows ref struct, but other cases like this I may not mention or forget we cause a new delegate type to be defined.

Therefore, I mean such types like SpanAction<,> can be re-use by only one defining rule, instead of creating a new type; delegate types are indeed heavy but they are the best choice to be declared as function-as-argument pattern, this cannot be fully solved by function pointers.

[HaloFour]

I don't see what this proposal does to address any of those concerns or differences between delegates and function pointers?

Also, with allows, it sounds like the plan is to amend Action/Func to permit ref struct type parameters. I believe there is some effort being applied to permit ref type parameters as well. Even then I feel Action/Func are way overused. I wouldn't use them anywhere that I also wouldn't be comfortable passing all state as a tuple. A properly defined type with proper names and proper documentation is much better for API surfaces that aren't super trivial.

[kyoyama-kazusa]

Both function pointers and delegates can make methods store like a normal data, this is why I compare delegate types with function pointers.

A function pointer can be used in 2 main reasons in my opinion:

1. Pass a method as an argument
2. Compatible with function pointers in C/C++

A delegate type can be also used in 3 main reasons (but now 2):

1. Pass a method as an argument
2. Event handlers
3. Compatible with function pointers in C/C++ (Because C# 9 introduces function pointers, this is not needed for now)

They have a same usage: pass a method as an argument, which is wanted to be emphasized by me above.