Repository navigation
[API Proposal]: GCHandle.GetTargetUnsafe() with no handle validation #94113
Description
Background and motivation
GCHandle is often used in scenarios (such as handwritten COM objects, or other interop setups) where callers have complete control over the handles, and nobody else is ever mutating them. The only way, currently, to get a target, is to use GCHandle.Target, which always incurs in a validation check, which is pretty much always just useless branching in these cases.
This proposal is about adding a way to get the handle target with no branches, when callers know no validation is needed.
API Proposal
namespace System.Runtime.InteropServices;
public struct GCHandle
{
+ public readonly object? GetTargetUnsafe();
}API Usage
// In a constructor (or wherever)
this.handle = GCHandle.Alloc(myObj);
// Later on
object? target = this.handle.GetTargetUnsafe();Alternative Designs
Alternatively (as @tannergooding also suggested), we could instead just remove the validation check from GCHandle.Target. This would technically be a breaking change, as it would cause invalid handles to throw a NullReferenceException instead of an InvalidOperationException, but it might be considered acceptable in this scenario, since it's a niche API.
The benefit of this approach is that no new API is needed, and everyone "gets faster for free".
Risks
With the new API, no risk.
With the alternate design, people taking a hard dependency on that exception type would break.
Activity
tannergooding commentedon Oct 27, 2023
Notably this suggestion came from the perspective that the current implementation is logically:
This means that these two calls should be logically the same, but they aren't:
We're already handling all kinds of invalid handles and most of them, outside
0, result in a NRE. So it might make sense to simply have0also cause a NRE. This removes the branch and makes the API overall more consistent.jkotas commentedon Oct 27, 2023
There are other similar inefficiencies in GCHandle:
And there is the cosmetic issue of GCHandle not implementing IDisposable (#54792).
We should consider all of them at the same time. We may want to consider introducing a new type that has all of them fixed.
Sergio0694 commentedon Oct 27, 2023
That type looks really nice 👀
If there is interest, what about opening a new proposal for that, linking all these ones, and try to get that to API review?
Sergio0694 commentedon Dec 24, 2024
Superseded by #94134, closing this.