[API Proposal]: change GCHandle<T>.ToIntPtr to be an instance method

[paulbartrum]

Background and motivation

I am interoping with unmanaged code a lot and so GCHandles are very useful. I was testing out the new GCHandle class, which is new in.NET 10 (see #94134). In general it's a big improvement, but I'd like to suggest a small change to ToIntPtr(), which is currently a static method and so unnecessarily requires writing the full type name, including the generic parameter type. This can be made less verbose by changing the method to be an instance method (see API usage).

API Proposal

public class GCHandle<T>
{
    // Was: public static IntPtr ToIntPtr(GCHandle<T> value);
    public IntPtr ToIntPtr();
}

public class PinnedGCHandle<T>
{
    // Was: public static IntPtr ToIntPtr(PinnedGCHandle<T> value);
    public IntPtr ToIntPtr();
}

public class WeakGCHandle<T>
{
    // Was: public static IntPtr ToIntPtr(WeakGCHandle<T> value);
    public IntPtr ToIntPtr();
}

API Usage

// Before:
var handle = GCHandle<MyClass>.ToIntPtr(new GCHandle<MyClass>(myClassRef));

// After:
var handle = new GCHandle<MyClass>(myClassRef).ToIntPtr();

Alternative Designs

Leave as is.

Risks

The change is not backwards compatible, but since the API has not been released outside of a preview, I believe the team considers this kind of break acceptable.

[jhudsoncedaron]

If you need it to be backwards compatible for whatever reason, do this:

public class GCHandle<T>
{
    public static IntPtr ToIntPtr(GCHandle<T> value);
    public IntPtr ToIntPtr();
}

But I think you don't.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[jkotas]

This was touched on during the API shape discussion. We have number of types that follow this shape #94134 (comment). This shape was chosen for consistency. I agree that it is more verbose than it needs to be, but that it is not uncommon in interop.

[jhudsoncedaron]

Oh well; at least this bad design choice can be fixed with extension methods.

[paulbartrum]

This shape was chosen for consistency.

Those Runtime*Handle methods were designed to be consistent with GCHandle, right? But the explicit goal of GCHandle<T> is to fix the API design mistakes from GCHandle, not to keep them in the name of consistency.

(I do agree that consistency is a worthy goal; I just think it is a lesser consideration in this case).

[colejohnson66]

Ideally, if a static method is desired, I'd say it should be GCHandle.ToIntPtr<T>(..) instead of GCHandle<T>.ToIntPtr. Then let the compiler elide the <T>. That fits more inline with what the runtime has done - ImmutableArray.CreateBuilder<T> for example.

[huoyaoyuan]

Ideally, if a static method is desired, I'd say it should be GCHandle.ToIntPtr<T>(..) instead of GCHandle<T>.ToIntPtr.

This should be avoided because of the clear separation between GCHandle and GCHandle<T>. Their IntPtr representations are intentionally not interchangeable, sharing the same type will cause confusion and misuse.

[agocke]

@Sergio0694 and @huoyaoyuan: you were strong advocates and implementors of this feature. Do you have a strong opinion on the shape here? The original proposal had ToIntPtr as a static method.

[Sergio0694]

I don't have a strong opinion, but I'm kinda leaning towards keeping them static, mostly for consistency. It's not just about the old GCHandle type (which in that case, sure, we could've said "well we're fixing that design"), but other types also use the same exact pattern, and I feel like it would be a bit odd to just have these two types here be slightly different.

For context: #67090 (comment).

Like, in hindsight ToIntPtr should've been an instance method, but given that the damage is done now and that we already also have RuntimeTypeHandle, RuntimeFieldHandle, and RuntimeMethodHandle doing the same, I'd just keep it that way.