Proposal: Add a relaxed unmanaged constraint that allows nullable types

[vmilea]

Motivation

Nullable<T> where T : unmanaged is effectively an unmanaged type (being a struct that contains fields of unmanaged types only). Unfortunately, it doesn't satisfy the struct / unmanaged constraints, which causes bloated APIs like:

void Write<T>(in ReadOnlySpan<T> values) where T : unmanaged { ... }
void Write<T>(in ReadOnlySpan<T?> values) where T : unmanaged { ... }

void Write<T>(in T value) where T : unmanaged { ... }
void Write<T>(in T? value) where T : unmanaged { ... }

This becomes exponentially worse the more parameters there are:

void Write<T1, T2>(in T1 a, in T2 b) where T1 : unmanaged where T2 : unmanaged { ... }
void Write<T1, T2>(in T1 a, in T2? b) where T1 : unmanaged where T2 : unmanaged { ... }
void Write<T1, T2>(in T1? a, in T2 b) where T1 : unmanaged where T2 : unmanaged { ... }
void Write<T1, T2>(in T1? a, in T2? b) where T1 : unmanaged where T2 : unmanaged { ... }

To avoid an explosion of overloads, the library author may decide to leave T unconstrained and instead throw an exception on misuse:

void Write<T1, T2>(in T1 a, in T2 b)
{
    // intrinsic checks will be optimized away
    if (!RuntimeHelpers.IsReferenceOrContainsReferences<T1>())
        ThrowHelpers.ThrowArgumentException(typeof(T1));
    if (!RuntimeHelpers.IsReferenceOrContainsReferences<T2>())
        ThrowHelpers.ThrowArgumentException(typeof(T2));

    ...
}

This approach detects issues at runtime with zero overhead, but the method signature no longer states the actual requirements and we lose compile time checks.

Since it's too late to change the semantics of the unmanaged constraint, why not add a relaxed form that allows the following?

void Write<T1, T2>(in T1 a, in T2 b) where T1 : unmanaged? where T2 : unmanaged? { ... }

Proposal

Define an unmanaged? constraint which doesn't imply struct, so it accepts both unmanaged T and T?.

Crucially, no CLR changes are needed -- from the perspective of the runtime, the type appears unconstrained. unmanaged? can be expressed through attributes on generic parameters and enforced at compiler level (similar to how nullable reference types are checked).

Alternative Designs

Register a code analyzer to constrain the parameters:

void Write<[Blittable] T>(in T value) { ... }

...

Write("oops") // Error: Type 'string' is not Blittable

This approach doesn't need compiler support, and could enforce additional rules like excluding auto layout types. However, processing all references for each annotated method and type may be too expensive with large projects.

Q/A

• Hasn't this been rejected already?

No. This proposal is for a separate constraint without breaking changes or CLR involvement.

• Should default value expressions be supported for unmanaged? types?

Yes. Zero initialization is fine for both unamanged T and Nullable<T>.

• Should unmanaged? imply the new() constraint?

While there's no technical reason preventing it, there's no practical benefit either since unmanaged types are typically zero initialized.

• What if our method needs to call other methods contrained to struct?

Losing access to minor utilities like MemoryMarshal.AsBytes<T>(Span<T> span) where T : struct is largely irrelevant since they can be easily reimplemented unconstrained through Unsafe. The essential operations are getting the size of T, its alignment, and access to raw bytes, neither of which requires the struct constraint.

[vmilea]

Discussion was moved from runtime. Thanks to @huoyaoyuan for the initial feedback.

[ufcpp]

It has come up in a discussion about ref struct.
#7971 (comment)

[jaredpar]

It's hard to see the value of this proposal. Given that unmanaged? constraint does not flow to unmanaged these API calls couldn't utilize many of the APIs in the runtime. Do you have a list of runtime APIs that you think would be candidatse to move to unmanaged? that would make this constraint more usable?

[vmilea]

Given that unmanaged? constraint does not flow to unmanaged these API calls couldn't utilize many of the APIs in the runtime.

This was covered in Q/A at the end. Do you have particular APIs in mind?

In my experience with unmanaged types we're just blitting or manipulating the raw data. This can be done without any constraints through System.Runtime.CompilerServices.Unsafe or unsafe blocks. For example, the unconstrained Write() method above may call Unsafe.Write(). So the issue as I see it isn't the runtime or APIs, just the compiler currently being too rigid.

Do you have a list of runtime APIs that you think would be candidatse to move to unmanaged? that would make this constraint more usable?

No API changes are necessary to make unmanaged? usable. In my own code I ended up reimplementing a few conveniences like System.Runtime.InteropServices.MemoryMarshal AsBytes() / AsRef() / Cast() because they are constrained to struct. These would be candidates for unmanaged?, except MemoryMarshal predates unmanaged types and it would be a breaking change.

[jaredpar]

This was covered in Q/A at the end. Do you have particular APIs in mind?

My question is assume that this proposal is implemented, what APIs in runtime would immediately move to use this new constraint? The reason I'm asking because in the absence of runtime using this constraint it's hard to see the value.

So the issue as I see it isn't the runtime or APIs, just the compiler currently being too rigid.

There is very little chance the compiler will introduce a constraint when the primary uses of values that have that constraint is Unsafe APIs.

[vmilea]

My question is assume that this proposal is implemented, what APIs in runtime would immediately move to use this new constraint? The reason I'm asking because in the absence of runtime using this constraint it's hard to see the value.

The value is in supporting libraries that build safer abstractions on top of Unsafe like high-performance serializers or memory-mapped data access. If such an API takes an unmanaged Span<T> it should work just as well with Span<T?>.

Regarding use in runtime: perhaps a redesign of MemoryMarshal is in order. I don't expect immediate uptake other than that, just like there hasn't been with plain unmanaged constraint.