Proposal: Struct Delegates

[timcassell]

Struct Delegates

Delegates, but with all the cruft trimmed away.

Today, we can declare whatever kind of delegate we want using this syntax:

public delegate void MyDelegate<T>(ref T arg);

And that essentially generates a class that implements MulticastDelegate.

public sealed class MyDelegate<T> : MulticastDelegate
{
    ...
}

This has lots of overhead with it, including the object overhead, multicast overhead, BeginInvoke overhead.

With Struct delegates we only use the bare minimum required to invoke (a struct containing an object instance and a pointer to an instance method).

Declaration syntax is just like with regular delegates, but with the struct keyword prepended.

public struct delegate void MyValueDelegate<T>(ref T arg);

And that generates a much simpler struct

public readonly unsafe struct MyValueDelegate<T> : IEquatable<MyValueDelegate<T>>
{
    private readonly object _instance;
    private readonly delegate*<this object, ref T, void> _mPtr; // Not currently expressible in C#
    
    // Possibly hidden in C# the same way regular delegate constructor is hidden.
    public MyValueDelegate(object instance, delegate*<this object, ref T, void> mPtr)
    {
        _instance = instance;
        _mPtr = mPtr;
    }
    
    public void Invoke(ref T arg) => _mPtr(_instance, ref arg);
    public bool IsValid => _instance != null && (IntPtr) _mPtr != IntPtr.Zero;
}

This type does not support multicast or Begin/EndInvoke.

With compiler support, constructing a struct delegate can be done in all the same ways as constructing regular delegates, using method groups or lambdas. Capturing vars or using a method group to a static function will result in the appropriate classes being generated the same way they are today. The only difference is the delegate itself is a 2-word-sized struct instead of a large class.

public interface IMyInterface
{
    void Invoke();
}

public class MyClass : MyInterface
{
    public void Invoke() { }
}

public static void M()
{
    IMyInterface instance = new MyClass();
    Func(instance.Invoke);
    
    /* Compiler lowers to
    
    // Not legal C# today, but it would use the Ldvirtftn IL opcode to get the instance method pointer.
    ValueAction action = new ValueAction(instance, &instance.Invoke);
    Func(action);
    
    */
}

public static void Func(ValueAction action)
{
    action.Invoke();
}

This results in zero allocations (not counting lambda captures) and super fast invoke.

Caveats

Because it's a struct, action?.Invoke() currently doesn't work the same way it does on regular delegates. It would be nice to have first-class language support where that is allowed and is simply lowered to a check to IsValid. But I'm not holding my breath.

Because it's a struct instead of a class, it could be torn if 2 threads read/write the same field. I think that shouldn't be a blocker, and could be solved by an Atomic<T> type

What about other allocation-free callback proposals?

There have been other proposals like #3452 and #1060. The difference is those proposals are using variable-sized generic structs, while this uses a fixed-sized struct. The advantage to those other proposals is even capturing variables can be alloc-free, while this would have to allocate a display class. The disadvantage is multiple callbacks cannot be laid out contiguously in memory like this fixed-size struct can. This makes it ideal for implementing a high-performance event library (not like C#'s events).

Also, struct delegates allow algorithms to cache the pointer to an interface method for improved performance without changing the API.

They both have their advantages and disadvantages and can co-exist.

--

Isn't this like Static Delegates?

No, that was for invoking static methods and was superseded by function pointers. This is for invoking instance methods the same way as regular delegates.

Alternatives

Rather than using struct delegate syntax to declare a delegate type, what about adding first-class support for arbitrary delegates? Similar to #5321, we could just write delegate<int, ref object, void> without explicitly declaring the struct delegate. This may be too large of an ask, but it would feel very natural imo.

--

Create your own struct delegate using existing function pointer support.

I have done exactly this. And while it does work, it is quite clunky.

unsafe
{
    ValueAction action = ValueAction.Create(this, &SInvoke);
    static void SInvoke(MyClass instance) => instance.Invoke();
}

That's way more verbose than

ValueAction action = Invoke;

And it requires unsafe code. Also, because it's invoking through a static function (because C# currently doesn't support instance function pointers #7331), it's slightly slower than it could be.

[TahirAhmadov]

Why isn't the del?.Invoke possible? Surely it can be ValueTask?? Also, if it's "zero", Invoke can just throw?

[timcassell]

The struct can't be null, but it could be defaulted with a null pointer. What would it do if you attempt to invoke it?

It would throw.

[TahirAhmadov]

Right, I would think both the null and the zero situations should throw.

For the zero, a new method can be added - InvokeIfNotDefault

[timcassell]

For the zero, a new method can be added - InvokeIfNotDefault

I like that idea. But what should the return type be? I would expect it to return a nullable result (if the result is a struct). I don't think that works with an unconstrained generic return type.

[TahirAhmadov]

Isn't the compiler generating each delegate struct from scratch? It can output any signatures it wants, including struct return value nullable etc.
For open generics like ValueFunc we simply don't generate this method.

[timcassell]

Only having that method on some delegates and not others doesn't sit well with me. I'd rather not have it at all in that case.

[ufcpp]

Similar to #1060

[timcassell]

I mentioned that in the What about other allocation-free callback proposals? section.

[GabeSchaffer]

A delegate to a static member function would have _instance == null, wouldn't it?

[timcassell]

What if the runtime can create and store the wrapper object inside the assembly of the static function? That would keep all the speed and keep the size down and keep the assembly alive.

[timcassell]

Or another idea is to store a strong reference to the MethodDesc in the wrapper class, then store the wrapper class in a ConditionalWeakTable<MethodDesc, StaticFunctionWrapper> (so only a single instance is created).

[KalleOlaviNiemitalo]

What if the runtime can create and store the wrapper object inside the assembly of the static function?

If code in the default assembly load context defines:

public struct delegate void D();
public class C {
    public void M<T>() {}
}

and code in a collectible ALC defines:

struct S {}
class U {
    D d = new D(C.M<S>);
}

and an instance of U is created, then the runtime would generate the wrapper class in the default assembly load context (where C.M is defined); but I think this would prevent the ALC of S and U from being collected ever. It would be nicer to keep that collectible, at least when the delegate construction expression is in that ALC, like above.

Or another idea is to store a strong reference to the MethodDesc in the wrapper class

AFAIK, MethodDesc is not a managed type and references to it are not understood by GC; but MethodBase could be used instead.

[timcassell]

So something like this (with all the appropriate checks, of course).

public readonly unsafe struct MyValueDelegate<T>
{
    private static readonly ConditionalWeakTable<MethodBase, StaticFunctionWrapper> s_staticWrappers = new();

    private sealed class StaticFunctionWrapper
    {
        private readonly MethodBase _method;
        private readonly delegate*<ref T, void> _fPtr;

        internal StaticFunctionWrapper(MethodBase method, IntPtr fPtr)
        {
            _method = method;
            _fPtr = (delegate*<ref T, void>) fPtr;
        }

        internal void Invoke(ref T arg) => _fPtr(ref arg);
    }

    private readonly object _instance;
    private readonly delegate*<this object, ref T, void> _mPtr;

    public MyValueDelegate(object instance, IntPtr mPtr)
    {
        if (instance == null)
        {
            // This doesn't looks like the correct API to get the MethodBase from the function pointer, but something along these lines...
            var methodBase = MethodBase.GetMethodFromHandle(RuntimeMethodHandle.FromIntPtr(mPtr));
            if (!s_staticWrappers.TryGetValue(methodBase, out var wrapper))
            {
                lock (s_staticWrappers)
                {
                    if (!s_staticWrappers.TryGetValue(methodBase, out wrapper))
                    {
                        wrapper = new(methodBase, mPtr);
                        s_staticWrappers.Add(methodBase, wrapper);
                    }
                }
            }
            _instance = wrapper;
            _mPtr = &wrapper.Invoke;
        }
        else
        {
            _instance = instance;
            _mPtr = (delegate*<this object, ref T, void>) mPtr;
        }
    }
}

[timcassell]

I think there might not be an API for the compiler to use to retrieve the MethodBase from the method pointer. Or I just can't find it. I suppose another option would be to wrap it in a regular delegate instead of a custom class (though it would incur the cost of the regular delegate).

[TahirAhmadov]

Regarding the static method discussion - why not just do:

public readonly unsafe struct MyValueDelegate<T> : IEquatable<MyValueDelegate<T>>
{
    private readonly object? _instance;
    private readonly IntPtr _mPtr; // it's just a method pointer, can we just put it in an IntPtr?
    
    // Possibly hidden in C# the same way regular delegate constructor is hidden.
    public MyValueDelegate(object? instance, IntPtr mPtr)
    {
        _instance = instance;
        _mPtr = mPtr;
    }
    
    public void Invoke(ref T arg)
    {
      if(_instance != null)
        ((delegate*<this object, ref T, void>)_mPtr)(_instance, ref arg);
      else
        ((delegate*<ref T, void>)_mPtr)(ref arg);
    }
    public bool IsValid => _mPtr != IntPtr.Zero;
}

[timcassell]

Because like @KalleOlaviNiemitalo explained, it needs to keep the referenced assembly alive to be considered "safe". Just storing the function pointer without an object reference won't do that.

[xoofx]

Completely concur with this proposal! Today I'm using similarly function pointers in lots of performance critical code to avoid the usage of delegates, but it comes with a painful experience (unsafe, explicit cast for fp...etc).