Feedback: boxed unions type test in type unions

[hez2010]

I'm opening this discussion to provide some feedback on the TypeUnions proposal.

In

csharplang/proposals/TypeUnions.md

Line 336 in dcea688

However, when neither type in the test is statically known to be related to a union struct, the type test will fail.

we have

bool IsType<T>(object value) => value is T;

U u = new A(...);
// always fails
if (IsType<A>(u)) {...}

This is because the language will not special case the type test when no union struct members are involved, since its not clear which type to check for. Checks for a common union interface could be made to work, but that would unduly impact the vast majority of type tests that do not involve union structs.

Today we are specializing code for value-type type parameters, so that IsType<A> will be specialized to its own code anyway.

Given this fact, here we can ask the JIT for some help: we can change the JIT to generate additional code for testing type against the union, only for specialized code whose type arguments are union structs.

Do note that this doesn't mean we are relying on the JIT impl details to implement the type testing. In general, we need to support union structs for all cases involving type testing, here what I'm talking about is an optimization that JIT can be smart so that it won't regress cases that are not involving union structs.

Implementation

The C# compiler emits an attribute [TypeUnionCase(typeof(<containing union struct>))] for union struct cases. Also it emits a generic version of TryGet<T> for use by the JIT.

Say now we have

union struct U
{
    A();
}

It got lowered to

struct U
{
    public bool TryGet<T>(out T value) {...};
}
[TypeUnionCase(typeof(U))]
struct A { ... }

When the JIT generates code for a method Foo<A>, it looks for TypeUnionCaseAttribute on the type argument A when A is a value type. If the attribute is found, in the import stage, the JIT fetches the union type U from the attribute and inserts additional code to do type test against the union so that the code

bool IsType<T>(object value)
{
    return value is T;
}

becomes

// specialized code for value type `A`
bool IsType<A>(object value)
{
    return value is U u && u.TryGet<A>(out _);
}

while for others like Foo<B> where B is a non-union struct or a class, the codegen won't be changed so the performance of type test against non-union types won't be regressed.

// specialized code for value type `B`, where `B` is not a union struct
bool IsType<B>(object value)
{
    return value is T;
}

// shared code for reference type
bool IsType<__Canon>(object value)
{
    return value is T;
}

We may also want to update the implementation of Type.IsSubclassOf to support this for System.Type. Type.IsSubclassOf is a JIT intrinsic so we can do this smart without regressing performance for most cases while providing fallback code for runtime that doesn't support this intrinsic.

Conclusion

In this way we don't need to change the code emitted by the C# compiler, also we don't regress the performance for cases other than union structs.

[timcassell]

I think people will be very confused to find that it works for struct unions but not class unions.

Also, will that work for AOT shared generics?

[hez2010]

1. union class is based on inheritance hierarchy where type testing already works out-of-box.
2. there's no difference between JIT and AOT for value-type specialization, it works for both JIT and AOT

[timcassell]

1. union class is based on inheritance hierarchy where type testing already works out-of-box.

Ah, makes sense.

2. there's no difference between JIT and AOT for value-type specialization, it works for both JIT and AOT

And what about cases where the specialization cannot be generated per type due to reflection MakeGenericMethod? AOT still has to create shared generics for those even if they are value types.

[HaloFour]

And what about cases where the specialization cannot be generated per type due to reflection MakeGenericMethod? AOT still has to create shared generics for those even if they are value types.

My understanding is that this is not possible with AOT with statically unknown types. As for JIT, I don't see why it wouldn't specialize that like it normally would. Otherwise it would have to box.

[timcassell]

My understanding is that this is not possible with AOT with statically unknown types.

It absolutely is possible, and is done by Unity's IL2CPP. https://unity.com/blog/engine-platform/il2cpp-full-generic-sharing-in-unity-2022-1-beta https://discussions.unity.com/t/unity-future-net-development-status/836646/1094 Though I have no idea if NativeAOT etc use the same code-gen strategy.

[hez2010]

AOT still has to create shared generics for those even if they are value types.

Then they need to handle things in the shared code.
As for NativeAOT, this is not a thing and every value type will be specialized.
MakeGenericType simply doesn't work for value types that don't have specialized code generated in NativeAOT.

[IS4Code]

I have proposed a general solution to this and a broader range of situations in the runtime repo (dotnet/runtime#105923), but I'd definitely appreciate seeing this addressed!

[timcassell]

I don't think that actually solves this case since we're dealing with 2 struct types. It needs to be unboxed to U then unwrapped to A. Users could type check for either or both types, and a custom boxing implementation by itself can't handle that.

[IS4Code]

@timcassell I think it could, depending on the implementation. If value is T is equivalent to checking that (T)value is valid, the runtime should be able to verify that an [IndirectlyBoxable] T can be boxed to the type of one of its active fields, and thus such a type must satisfy is T.

The attributes (for option A in the proposal) basically give off the same information as [TypeUnionCase] here.