[API Proposal]: RuntimeHelpers.ChangeType<TDelegate>(Delegate) API

[Sergio0694]

Background and motivation

We're currently using Unsafe.As<T>(object) quite a bit to optimize our messenger types in the MVVM Toolkit (https://aka.ms/mvvmtoolkit/docs), but I've been thinking for a while now that it'd be nice to remove that call to avoid relying on implementation details of the runtime to make things work, and to make the functionality safer in the future. Just to recap on the current setup (I've added a more extensive summary here), we basically have this (simplifying):

// The message handler delegate, whic is generic on the recipient type
public delegate void Handler<in TRecipient>(TRecipient recipient)
     where TRecipient : class;

// Message broadcast
object handler = GetTheHandler();
object recipient = GetTheRecipient();

Unsafe.As<Handler<object>>(handler)(recipient); // yehaa! 🤠

Now, this works fine because we're always passing the "right" recipient, so the actual type safety when the delegate is invoked is respected. But, we're still aliasing a reference type with a type that doesn't actually match the one of the target instance, and even though the runtime/GC are fine with this now, it's not really ideal, so to say. It works, though.

As @jkotas mentioned in our previous conversation on this (here),

"The specific use of Unsafe.As that you have highlighted sounds reasonable to me. I understand that the generic constrains are not always expressive enough to do what you need."

Despite there not being a way to do this via the language (it's also arguably a pretty niche feature, though I know I'm not the only one using this), I was thinking it would be nice to at least explore some options to do this in a way that doesn't rely on aliasing reference types with incompatible types and potentially causing GC issues on other runtimes and whatnot.

cc. @GrabYourPitchforks as we've been talking about this quite a lot in the #lowlevel C# Discord 😄

Related issues:

• Stop hiding function pointer delegate constructor csharplang#4871: this requires a language change and it would also not work when eg. a delegate is wrapping a dynamic method, as those don't allow retrieving the method handle and the function pointer. The proposed approach instead would work with any delegate instance.
• API to change a delegate's type to a signature-compatible different delegate type #45408: this was rejected due to the request to add potentially expensive runtime type checks. That wouldn't be the case here: the proposed API would just ask the runtime to create a delegate of the new type, by copying all the internal fields (so target instance, function pointers including optional stub, etc.). This would also make it so that the proposed approach would work fine when the delegate is generated from a dynamic method, as mentioned above.

API Proposal

namespace System.Runtime.CompilerServices
{
     public static class RuntimeHelpers
     {
          public static TDelegate ChangeType<TDelegate>(Delegate del)
              where TDelegate : Delegate;
     }
}

NOTE: the returned delegate would not just be a new delegate wrapping the input one, but a new instance of the requested type with the same internal state, resulting in the same method/target being used when invoked.

API Usage

// Message registration
ref object storedHandler = ref GetTheHandler();

storedHandler = RuntimeHelpers.ChangeType<Handler<object>>(handler);

// Message broadcast
object handler = GetTheHandler();
object recipient = GetTheRecipient();

((Handler<object>)handler)(recipient);

Same functionality, hopefully negligible performance loss during broadcast (I could also keep using Unsafe.As<T>(object) there if that variant cast was noticeable, but at least the behavior there would now be safe and no longer aliasing an invalid type), and no longer relying on hacks to make the whole thing work while being fast and without reflection 😄

Risks

Low risk. Changing the delegate type to an invalid type could result in crashes and type safety violations at runtime when the new delegate is invoked. But the API would be in an inherently unsafe type and namespace, so only advanced users knowing what they're doing would ever see the API, let alone actually use them in their code. Besides, you can still do all sorts of ugly things with Unsafe.As<T>(object) anyway, which is also in the same namespace 🙂

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]

the proposed API would just ask the runtime to create a delegate of the new type, by copying all the internal fields (so target instance, function pointers including optional stub, etc.).

So this would be type unsafe API. Is it really that much better than Unsafe.As that you are using today?

[Sergio0694]

It would still be unsafe, yes. Callers would have to "pinky swear to respect the original type constraints" (quoting from Levi).
The main advantage would be that it would avoid the whole aliasing reference types of incompatible types at runtime, which though it works fine on CoreCLR/Mono now, I'm not entirely sure it's... Uh... Necessarily a good thing to do 😄

[jkotas]

I think if we were to introduce an API for this, it should be proper type-safe API. Yes, it will be slow, the simple initial implementation at least, but that's fine.

[Sergio0694]

Would such a safe API actually work in this scenario though? Like, in this case I'm deliberately breaking type safety, in that I have a contravariant type parameter in a delegate and I'm converting the signature to accept a less derived type instead, only with the guarantee that the type will match at runtime. Like, if the API was to check the signature at instantiation time, wouldn't that throw because the signature of the new delegate (eg. Action<string> ---> Action<object>) doesn't match?

Partially related question, mostly out of curiosity: should the current Unsafe.As<T>(object) trick working on CoreCLR/Mono be considered as relying on implementation details or is that technically fine according to ECMA as well? I've gone through the relative chapters but I'm still not entirely sure about this. Like, it should work but it's not like ECMA specifically makes any guarantees on VM/GC behavior if one decides to alias incompatible types at runtime. 😄

[alexrp]

Unsafe definitely relies on implementation details, and not just casting. IIRC, there's no particular guarantee in Ecma 335 that managed pointers have to be represented as actual pointers at all; an implementation could conceivably use some weird kind of GCHandle to implement managed pointers if it really wanted.

That said, the assumptions Unsafe makes are reasonable in practice. It's unlikely that any Ecma 335 implementation wouldn't be compatible with them.

[jkotas]

is that technically fine according to ECMA as well?

The ECMA does not generally say anything about the behavior when the type safety is violated. Since you would be still violating type safety even with this API (I have missed that in your write up), it would still be in the gray area.

It's unlikely that any Ecma 335 implementation wouldn't be compatible with them.

I think the highest risk of incompatibilities come from codegen optimizations. Some of the advanced codegen optimizations assume type safety. Your code may break in odd ways with type safety violations. (This is a potential problem. I do not have an actual example in hand to demonstrate this problem.)

[Sergio0694]

"I think the highest risk of incompatibilities come from codegen optimizations. Some of the advanced codegen optimizations assume type safety."

Yeah, I remember @AndyAyersMS the other day was just about talking about how the fact we can now alias reference types might interfere with some JIT optimizations that might potentially have to be reverted, though Levi also said we might just decide not to care about people deliberately breaking type safety like that and avoid the performance regression for others not doing similar hacks (so almost everyone). Point is, this was one of the reasons why I wanted to at least start a conversation about potentially finding a safe (or at least, properly supported) way to achieve what I described in this issue, without relying on type aliasing 🙂

"Since you would be still violating type safety even with this API [...], it would still be in the gray area."

What I'm saying though is that assuming consumers of this API (advanced users that know exactly what they're doing) do respect the actual type constraints of arguments passed during involution (like I mentioned in the issue), you would effectively no longer have any type safety violations though, no? I mean of course if you then passed invalid params you'd break type safety, but if not, everything would then be valid and no longer relying on hacks. No reference type aliasing with incompatible types or anything, you'd just be invoking a delegate with a valid type (created by the runtime), wrapping a method that accepts parameters that are valid with the ones you're passing. So that'd be... Safe? 😄

[GrabYourPitchforks]

If we had a safe API I'd like it to hang directly off the Delegate type for discoverability.

If we wanted to have an unsafe API to create a delegate wrapped around an arbitrary 'this' object and function pointer, would it be sensible to expose the delegate ctors via dotnet/csharplang#4871 as previously mentioned? I had batted around the idea of a separate unsafe API for this a while back, but the feedback I got was that exposing the ctors would make a new unsafe API redundant.

@jkotas When you say violating type safety, are you referring to undefined behavior? ECMA does call out scenarios which are type-unsafe but which have well-defined behavior assuming the caller operates within some boundaries. But I don't know where this particular scenario falls. My understanding of the scenario is that Sergio wants a delegate whose parameter is typed as TBase but where the target method has a parameter typed as TDerived, and he pinky swears that he'll only ever pass a TDerived into the delegate's invoke method.

[GrabYourPitchforks]

Maybe an example would help my understanding. Ignore the Delegate type for a sec. Let's say I have this code:

static void DoIt(string s) { /* ... */ }

delegate*<string, void> del1 = &DoIt;
delegate*<object, void> del2 = (delegate*<object, void>)(void*)del1;
del2("Hello!");

It's clearly not type-safe to have an object -> void fnptr pointing to a string -> void method. But is it undefined behavior?

[Sergio0694]

"would it be sensible to expose the delegate ctors via dotnet/csharplang#4871"

One of my issues with that is that that would also crash if the delegate is wrapping a dynamic method (not sure if there's other cases too). So that would be a regression for the MVVM Toolkit, for instance. I know that's arguably a niche scenario, but I also have no idea what all consumers of the library are doing with it, so I wouldn't want to switch to an alternative solution that would not work in some scenarios that are instead fully supported today 😥

"My understanding of the scenario is that Sergio wants a delegate whose parameter is typed as TBase but where the target method has a parameter typed as TDerived, and he pinky swears that he'll only ever pass a TDerived into the delegate's invoke method"

Yup, that is exactly right 😄
I will absolutely pinky swear to respect the type safety of the arguments that I pass when invoking, but my issue is that my broadcast methods cannot know what type arguments each stored handler have, so the only way to invoke them is to just lie and downcast each delegate to accept an object in place of each TFoo, and then relying on the fact that each recipient we retrieve for each invoked delegate is the right one.

[jkotas]

expose the delegate ctors

Note that the raw delegate ctor resolves the pointer back to MethodDesc first (that is about as expensive as going to MethodInfo), then it compares the signatures of the MethodDesc and the delegate, based on how the signatures compare creates the various thunks to shuffle the arguments, and finally creates the delegate.

The JITed code only calls the raw delegate ctors as fallback in rare situations (e.g. error cases like signature mismatches). For the common cases, the JIT treats the ldftn + delegate ctor pair as intrinsic, all of the above happens at JIT time and JITed code just calls a specific helper for the given delegate case.

So creating the delegate via the raw delegate ctor would be about as fast as creating the delegate from MethodInfo. None of current JIT optimizations would kick in. Is that still useful? Why not just create the delegate from the MethodInfo in the first place instead of going through function pointers?

When you say violating type safety, are you referring to undefined behavior?

Yes. For example: The delegate can be bound virtually. In future, we may do delegate inlining and speculative devirtualization for this case. Is it going to work properly when some of the signatures involved violate type safety? I would not bet on it.

[jkotas]

The guideline that I have shared at #6176 (comment) still sounds about right.