[API Proposal]: Support ignoring generic constraints with UnsafeAccessor

[MichalPetryka]

Background and motivation

In .NET 10 UnsafeAccessor got support for inaccessible types with UnsafeAccessorType, however that doesn't help for types used as generic constraints.

As such, I'd like to request an option for ignoring the constraints, as originally discussed in #99468 to be exposed, since that'd solve this issue and additionally would allow the use of UnsafeAccessor for generic bridging.

The constraints here would still be resolved lazily, on per instantiation basis, to avoid type safety issues, either at compile time or at runtime when not possible due to shared generics.

API Proposal

namespace System.Runtime.CompilerServices;

public sealed class UnsafeAccessor : Attribute
{
    public bool IgnoreGenericConstraints { get; }
}

API Usage

// assembly A
internal IInacessible {}

public class C
{
    internal void A<T>(T val) where T : IInacessible {}
}

// assembly B
[UnsafeAccessor(UnsafeAccessorKind.Method, Name = "A", IgnoreGenericConstraints = true)]
public static extern void A<T>(C c, T val);

Alternative Designs

Since you can't overload on constraints in both IL and C#, this could be changed to be the only behaviour but it'd be a breaking change.

Risks

This would be problematic if overloading by constraints was added in future IL changes, cases that could need runtime checking would have reduced performance.

[dotnet-policy-service]

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

[DaZombieKiller]

This would also allow a developer to work around the lack of ability to bridge generic constraints:

using System;
using System.Numerics;
using System.Runtime.InteropServices;
using System.Runtime.CompilerServices;

class Program
{
    static void Main()
    {
        Console.WriteLine(Number.Add(null, 1, 1));
    }
}

static class Number
{
    private static T AddCore<T>(T x, T y)
        where T : INumber<T>
    {
        return x + y;
    }

    [UnsafeAccessor(UnsafeAccessorKind.StaticMethod, Name = "AddCore", IgnoreGenericConstraints = true)]
    public static extern T Add<T>([UnsafeAccessorType("Number")] object? _, T x, T y);
}

This actually already works under Mono. It does not validate the generic constraints of unsafe accessor methods currently.

[tannergooding]

This likely needs some weigh in from @jkotas and/or @davidwrighton before we take it through API review.

We'd like to confirm that the feature is even possible for RyuJIT (things already "just work" without the API under Mono, as per the above) and that the name/shape looks correct. That is, whether the single property looks sufficient or if we potentially need a different name/shape to account for some current or future runtime nuance around generic constraints.

[jkotas]

Since you can't overload on constraints in both IL and C#, this could be changed to be the only behaviour but it'd be a breaking change.

Right, it is the solution that was discussed in #99468 (comment) and related discussions.

It would not be a breaking change since it is changing an exception into a reasonable behavior. Change like that is allowed change per https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-change-rules.md#exceptions .

Removing api-ready-for-review since this solution does not require any new APIs.

[jkotas]

cc @AaronRobinsonMSFT

[AaronRobinsonMSFT]

This actually already works under Mono. It #102942 of unsafe accessor methods currently.

Yep. We will be enforcing constraints in CoreCLR at run-time.

[AaronRobinsonMSFT]

/cc @agocke