Proposal idea: 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 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.

It's too late to change the semantics of the unmanaged constraint, but why not add a relaxed form to allow the following?

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

Proposal

Define an unmanaged? constraint which accepts both unmanaged T and T?. It still implies the new() constraint, but not struct.

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

[huoyaoyuan]

unmanaged constraint is not a CLR concept. It's not respected by CLR and reflection. Creating new constraint types is fundamental work and requires unmanaged constraint to be established in the front.

Additionally, Nullable<T> uses Auto layout, so it can be problematic for writing it directly.

[vmilea]

Thanks, I appreciate the feedback.

This won't work properly. If the method/type needs to call other method constrained to struct, it won't be satisfied at CLR level.

The lack of struct is largely irrelevant: we lose minor utilities like MemoryMarshal.AsBytes<T>(Span<T> span) which 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.

However, even for fully blittable types, dumping memory can still cause problems because of endianness.

Thankfully little-endian is ubiquitous nowadays. :)

[vmilea]

Just realized I've created this discussion in the wrong project. Can it be moved to csharplang while preserving comments?

[huoyaoyuan]

It can be, but it doesn't belong to csharplang. It's restricted by CLR type system and can't be solved currently.

[vmilea]

It can be, but it doesn't belong to csharplang. It's restricted by CLR type system and can't be solved currently.

As explained, no CLR change is necessary. In fact we can already achieve similar results through attributes enforced by a code analyzer. So I think csharplang is the right place for it.

[huoyaoyuan]

As it doesn't imply any constraint other than new, it may be encoded as unconstrained.

To be supported in the language, it needs to express a strong desire. Otherwise, the customized analyzer+attribute approach will be suggested.