API to change a delegate's type to a signature-compatible different delegate type

[Joe4evr]

Background and Motivation

Inspired by a pair of comments between @GrabYourPitchforks and @jkotas at #4556 (comment)

Say that I have a Predicate<string>, but I need a Func<string, bool>. There's one kinda-hokey workaround right now:

Predicate<string> del1 = GetDelegate();
Func<string, bool> del2 = del1.Invoke; // points to Predicate<string>.Invoke's MethodDesc

But this isn't ideal since it's a hidden recursive operation: every invocation incurs an extra indirection.

Since Jan said this should be a separate API, here we are.

Proposed API

namespace System
{
    public abstract partial class Delegate
    {
        [return: NotNullIfNotNull("del")]
        public static TDelegate? ChangeType<TDelegate>(Delegate? del) where TDelegate : Delegate;
    }
}

This method is Null-in-Null-out. Exception behavior may be as follows:

• T is an incompatible delegate type (InvalidCastException?)

Usage Examples

Predicate<string> del1 = GetDelegate();
Func<string, bool> del2 = Delegate.ChangeType<Func<string, bool>>(del1); // points to whatever MethodDesc del1 pointed to

Alternative Designs

¯\_(ツ)_/¯

Risks

None that I can think of.

History

• Removed Try-pattern methods
• Removed non-generic method

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jkotas]

But this isn't ideal since it's a hidden recursive operation: every invocation incurs an extra indirection.

You can avoid the extra indirection by deconstructing the delegate, e.g. something like:

Func<string, bool> del2 = del1.Method?.CreateDelegate<Func<string, bool>>(del1.Target) ?? del1.Invoke;

This fragment avoids the indirection for the simple single-cast delegates only. It is possible to extend this to handle multi-cast delegates too, but the relative benefit for multi-cast delegates is much less (multi-cast delegates pay for indirection that is much more expensive than the indirection via Invoke method). Same holds for special delegate kinds like marshaled function pointers.

The assumption behind this API is that the runtime can do the retype in signficantly cheaper way than the above fragment.

This API has to do a signature match that is an relatively expensive operation. Even though the API does not have MethodInfo in its signature, it would be in the same performance category as other reflection APIs that operate on MethodInfo and method signatures.

[jkotas]

Stretch goal: Try-pattern methods

I do not see a good reason for having Try-pattern methods for this. There are no Try-pattern methods that deal with creation of delegates today.

The only method that is needed for the scenario described in the motivation is the non-Try generic overload.

[huoyaoyuan]

I remember that:

Predicate<int> p = XXX;
Func<int, bool> func = new Func<int, bool>(p);

would success.

[GrabYourPitchforks]

@huoyaoyuan Good eye. That results in identical codegen to the Func<int, bool> func = p.Invoke; case: a delegate wrapping a delegate.

A naïve implementation of the proposed ChangeType API could special-case unicast invocations and transfer the method handle + target object into the new delegate instance, per Jan's suggestion, and multicast / unmanaged / ARM64 stub invocations could be implemented as delegate-wrapping-delegate for simplicity. That at least gets the API out the door. It also allows us to optimize the latter cases in a future release without needing to go through API review again.

[Joe4evr]

I do not see a good reason for having Try-pattern methods for this. There are no Try-pattern methods that deal with creation of delegates today.

The only method that is needed for the scenario described in the motivation is the non-Try generic overload.

Alright, updated the OP.

[jkotas]

The expensive part of this API implementation is the signature match check to prove that the retyping is type safe.

I am wondering whether it would be better to have a static T Optimize(T del) where T: Delegate method that takes a delegate and restructures it for maximum performance. It can remove the extra delegate to delegate indirections discussed here, inline shufle thunks in future, etc.

[steveharter]

Should this be in the area-TypeSystem-coreclr instead of reflection?

[buyaa-n]

As this has a workaround @jkotas mentioned here and the proposed API has to do a relatively expensive signature match, we don't think this API could be more performant than the existing workaround, therefore closing the proposal. @Joe4evr, @GrabYourPitchforks feel free to reopen if you have a different opinion