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)