This seems unusual. Why would we checking this? For example, the foreach pattern doesn't ensure that Enumerator.Value has a get but no set, it only checks for the get being present. #Resolved

This seems unusual. Why would we checking this?

This is how the spec defines the API. I can see that there could be other interpretations. I will capture a clarification question in the spec.

Nit: verifier is unused. And a few others.
#Resolved

Consider a generic constraint case, something like:

interface IA
{
    bool HasValue { get; }
}

static void Test1<T>(T t) where T : IA, IUnion
{
    _ = s is null;
}
``` #Resolved

Consider a generic constraint case, something like ...

Perhaps I am missing something. Type parameters aren't union types regardless of constraints, and aren't subject for union matching.

Perhaps I am missing something. Type parameters aren't union types regardless of constraints, and aren't subject for union matching.

Interesting. The wording in the spec is "Any non-abstract class or struct type that implements the IUnion interface is considered a union type.". I think that means that a type parameter constrained to IUnion, struct should be considered a union type, no?

In general, type parameters are not classes or structures. They can be reference types or value types. Also, some union behaviors require constructors, type parameters do not have those. Since the spec doesn't explicitly say what scenarios are supposed to work with type parameters, I interpret that as: "Union behaviors aren't applicable to type parameters." However, I requested a clarification - https://github.com/dotnet/csharplang/blob/main/proposals/unions.md#confirm-that-a-type-parameter-is-never-a-union-type-even-when-constrained-to-one

There is also a test reflecting the fact - UnionMatching_35_TypeParameter