[Proposal] Better interop between function ptr and delegates

[sakno]

Motivation

C# 9 introduces a syntax for obtaining function pointers. But original PR nothing says about interop with regular delegate types and possibility to create delegate instance from function pointer.

Goals

1. Allows to create open delegate using function pointer
2. Allows to create closed delegate using function pointer

Non-Goals

1. Support of ExplicitThis managed calling convention by function pointer syntax

Proposal

C# compiler may allow to pass function pointer as an argument of delegate constructor:

delegate*<int, void> ptr = &SomeFunction;
Action<int> action = new Action<int>(ptr);

The type of the argument should be a typed function pointer. Type void* is not allowed. Additionally, the compiler can control the calling convention at compile time:

• managed calling convention is compatible with any delegate not marked with UnmanagedFunctionPointerAttribute attribute
• cdecl, thiscall, stdcall convention is compatible with the delegate marked with UnmanagedFunctionPointerAttribute attribute with appropriate calling convention.

Closed delegate can be created from pointer to managed function only. Implicit first argument can be passed as the second argument of delegate constructor:

static int NextValue(Random rng) => rng.Next();

delegate*<Random, int> ptr = &NextValue;
Func<int> action = new Func<int>(ptr, new Random());

Alternatives

Marshal.GetDelegateForFunctionPointer method can be improved to allow generic delegates. However, such approach allows to use incorrect calling convention.

[mitsakos24]

ethereum_book/code/OpenZeppelin/contracts/SampleCrowdsale.sol

[tannergooding]

@sakno, you might consider rewording this so that it proposes C# stop hiding the existing delegate constructor which takes a function pointer.

That is, every delegate currently generated exposes the following (noting that the actual language spec may have slightly different rules here, this is what the compiler emits today for CIL and that some TFMs may be lacking Begin/EndInvoke):

public void .ctor(object @object, IntPtr method);
public virtual void Invoke();
public virtual IAsyncResult BeginInvoke(AsyncCallback callback, object @object);
public virtual void EndInvoke(IAsyncResult result);

The first method (the constructor) takes the this that the delegate is bound against, if any, and the function pointer (as an IntPtr). Conceivably, the compiler could stop hiding this public method and could optionally allow that the method parameter is a correctly typed function pointer.

[sakno]

I don't think that this is just about hiding the ctor. Having this object as a first parameter may be inconvenient especially when we want to see open/closed delegate support. That's why I suggest to have two pseudo constructors treated by C# compiler in a special way, e.g.

public sealed class Action<T> : MulticastDelegate
{
   public void .ctor(delegate*<T, void> method);
   public void .ctor<TTarget>(delegate*<TTarget, T, void> method, TTarget obj) where TTarget : class;
}

Of course, these ctors are recognizable only by C# compiler and no need to change CIL and ECMA specs related to Delegate constructors.

[sakno]

The same is application to pseudo implicit operator that can be supported by the compiler for each delegate type.

[svick]

@tannergooding Doing that would make this a duplicate of #4871.

[tannergooding]

Having this object as a first parameter may be inconvenient especially when we want to see open/closed delegate support

Today, the JIT specially recognizes and handles the IL pattern of ldftn followed by calling .ctor(object @object, IntPtr method). This pattern is what gets emitted today whenever you create a delegate.

Adding any other constructors would not be as efficient by default (may just be convenience overloads) and would also make this feature inaccessible to the 20 years of existing delegates that have already been compiled and emitted.

[sakno]

These constructs are synthetic constructors recognizable by Roslyn compiler at source level. They don't need to be exist on IL level at all. In other words, it's just a syntactic sugar.