Design to support ByRefLike types in Generics

[AaronRobinsonMSFT]

Adding in a proposal to support ByRefLike type in Generics. This work is supported by #63768 and contributes toward #65112.

/cc @jkotas @davidwrighton @jaredpar @cston @RikkiGibson @AlekseyTs

[danmoseley]

Cc @steveharter

[AaronRobinsonMSFT]

@lambdageek for mono and @tgani-msft for C++/CLI FYI.

[AaronRobinsonMSFT]

Any other feedback on this design?

[tgani-msft]

Are these types importable via the COM metadata APIs? The C++ compiler uses only these.

[AaronRobinsonMSFT]

@tgani-msft As in, can they be acquired through the IMetaDataImport interface? Yes. A new enum value is being added though. That will need to be updated. Can you share an example of how the compiler uses IMetaDataImport so we can record the pattern?

[tgani-msft]

@tgani-msft As in, can they be acquired through the IMetaDataImport interface? Yes. A new enum value is being added though. That will need to be updated. Can you share an example of how the compiler uses IMetaDataImport so we can record the pattern?

I'll send you a link to the source code directly, via email.

[RikkiGibson]

I think this came up elsewhere (maybe from @teo-tsirpanis), but is there any need to take special effort to make types "conditionally by-ref-like" depending on their type arguments? For example, imagine if we wanted to let people use nullable ref structs. It would be good to allow things like boxing, heap escape, etc. depending on the type arguments.

ref struct RS
{
    public ref int X;
}

namespace System
{
    // somehow we denote here that this is "only a ref struct if T is a ref struct".
    public struct Nullable<T> where T : struct allow T : ref struct // or whatever syntax we use
    {
        T value;
        // ...
    }
}

void M(RS? maybeRs, ref int X)
{
    if (maybeRs != null)
    {
        maybeRs.Value.X = ref X;
    }
    object obj = maybeRs; // error
}

void M2(int? maybeInt)
{
    object obj = maybeInt; // ok
}

It's possible the answer here is no, don't bother doing this, or punt it to something further down the line, but seems worth considering as part of this whole area.

[AaronRobinsonMSFT]

but is there any need to take special effort to make types "conditionally by-ref-like" depending on their type arguments?

That seems like a much broader feature given T would now influence the use of the Generic type. For example, if this were to be implemented we would also need to update the semantics of IsByRefLikeAttribute or create another mechanism that is predicated on other features. At present, I don't see anything here that would limit this, but do have some concerns about this feature and the complexity it would introduce in the type system and runtime in general.

[AaronRobinsonMSFT]

The only prior art I can think of for this sort of thing is in Interop when a T influences the blittability of a type.

[RikkiGibson]

FWIW, there are a few existing places in the compiler where the types of fields after substitution affect usage of a struct. For example: SharpLab. (it sounds like this might be very similar/related to blittability.)

struct S<T>
{
    public T field;
}

class Program
{
    unsafe void M1(S<int>* ptr) { } // ok
    unsafe void M2(S<object>* ptr) { } // error
}

[AaronRobinsonMSFT]

FWIW, there are a few existing places in the compiler where the types of fields after substitution affect usage of a struct. For example: SharpLab. (it sounds like this might be very similar/related to blittability.)

Agreed, but not metadata. For example, the following might be unintuitive from a reflection standpoint:

struct S<T> allow T : ref struct
            ref struct when T : ref struct
{ }

Console.WriteLine(typeof(S<>).IsByRefLike); // False
Console.WriteLine(typeof(S<int>).IsByRefLike); // False
Console.WriteLine(typeof(S<Span<int>>).IsByRefLike);  // True

[hez2010]

How about enabling overload by generic constraints so we can have both Foo<T> where T : struct and Foo<T> where T : ref struct?

[stephentoub]

@AaronRobinsonMSFT, can this be merged? Presumably we're fine updating the design doc as the design evolves and we don't need to block the PR on having 100% of the answers set in stone?

[AaronRobinsonMSFT]

@AaronRobinsonMSFT, can this be merged?

I think so. It is accurate regarding the current state of support in the runtime.

Presumably we're fine updating the design doc as the design evolves and we don't need to block the PR on having 100% of the answers set in stone?

Agreed.