Discussion: Union and Intersection types

[gulshan]

I first learned about Union and Intersection types from Typescript. What I think is the most important concept I learned about them is-

• Union of types means intersection of their members (has common members of all participating types).
• Intersection of types means union of their members (has any member of any participating type).

I like to refer Union type as "Or type" and Intersection type as "And type", for simplicity. In Typescript, just like JavaScript, types are mostly dictionaries of string keys and members of different types as values. So, the union or intersection (based on the keys) of the members from different types is actually possible to generate a new type. So, the concept makes sense in TS/JS world. But in world of C# and .net, I don't think union or intersection of members is a natural idea, even if possible. So, the question is, how the Union/Or types and Intersection/And types should look like in C#?

In my opinion, in C#, union or intersection of types should be defined by inheritance (type hierarchy). Which means, the Union or Intersection of types should produce implicit abstract classes or interfaces instead of concrete types. Then an union of types would mean an implicit base type of the participating types, while an intersection of types would mean an implicit child type of the participant types. That means-

• Union/Or of types T1 and T2, T1 | T2 will be defined as an implicit abstract base type of T1 and T2. Any object or value of type T1 or T2 will also be implicitly considered of type T1 | T2.
• Intersection/And of types I1 and I2, I1 & I2 will be defined as an implicit abstract child type I1 and I2. If a object or value derives from or implements both type I1 and I2, then it will be implicitly considered of type I1 & I2.

As we can see, Intersection/And of types requires multiple inheritance. In .net view multiple inheritance, there can be only a single parent class (optionally) but multiple interfaces. So, following the same rule, we should allow only one single class in an Intersection/And type, while the rest of the participant types should be only interfaces. For Union/Or types, as all classes and interfaces implicitly inherits the Object class, no such restriction is needed in my opinion.

Syntax:

There can be two types of syntax to define Union and Intersection types- unnamed and named. As I have already used above, the unnamed (inline) definition can use | for Union and & for Intersection. T1 | T2 is Union of T1 and T2 while I1 & I2 is Intersection of I1 and I2. And the named definition can just be the aliases of unnamed definitions. C# currently only have the file-wide type aliasing with using. But programmatical project-wide type aliasing is being discussed in #259 . I would prefer using a new and explicit keyword for aliasing like typealias. Then the named definition will look something like-

public typealias SignedNumber = short | int | long | float | double | decimal;
public typealias IReaderWriter = IReader & IWriter;

An alrernative for & can be +, which is used in some other languages like Rust-

public typealias IReaderWriter = IReader + IWriter;

Both #228 and #344 are already discussing intersection of interfaces. #228 suggested to use union<I1, I2> (it should be intersect<I1, I2> IMHO) as unnamed definition, while #344 initially suggested this syntax-

implicit interface IReaderWriter : IReader , IWriter {}

While this syntax looks more idiomatic to C#, it cannot be declared inline, which is sometimes nice to have.

Members:

Which from the participating types should become the members of the resultant Union and Intersection types? For Intersection/And types aka union of members, the answer is quite simple, all of them. If there are some actually common member/API? It should not make much difference, unless explicitly implemented by the concrete type. Then the API has to be implemented implicitly or explicitly for all interfaces of Intersection/And type.

For Union/Or type, I think we should go for members of the "most common type" in the inheritance tree. In many cases, it will be just object. But if any of the participating type overrides some member of that common type, a call to the member will correspond to the participating type, not the common type. There was a discussion regarding best common type in #33 , but it got stuck in the question, should interfaces be considered. Here the "most common type" does not include interfaces. But if all participating types implements an interface but the "most common type" does not, the members of that particular interface should still be available to the Union/Or type through that interface.

In short, we just follow the current rules of C#/.net type hierarchy. And, also there can be extension methods to Union/Or and Intersection/And types.

Usage:

As already mentioned, usage of Intersection/And types (for interfaces) are already being discussed in #228 and #344 . For Union/Or types, there can be following cases-

• Java like exception handling-

try { ... }
catch (CommunicationException|SystemException ex) {
    //handle the exception
}

• Pattern matching-

if (result is short|int|long number)

• As type constraint-

public class GenericClass<T> where T : T1 | T2 | T3

• Typed heterogeneous collections-

var inputs = new List<int|double|string>{3, 9.9, "abc"};

• Resultant type of combination of variables/values/expressions of different types through ? :, ?? or switch expression combinators-

var result = x switch { true => "Successful", false => 0 };
// the type of result here will be- string|int

• If multiple overloads of some method have same implementations, Union type can do the job-

void logInput(int input) => Console.WriteLine($"The input is {input}");
void logInput(long input) => Console.WriteLine($"The input is {input}");
void logInput(float input) => Console.WriteLine($"The input is {input}");

// Can be changed to-
void logInput(int|long|float input) => Console.WriteLine($"The input is {input}");

• Maybe as return types-

public int|Exception Method() {...} // returning exception instead of throwing

I think, as there is no actual intersection of members in this proposed unions types, they will also act like discriminated unions of some sort (which is being discussed at #75 and #113 )-

public class None {}

public typealias Option<T> = T | None; // Option type

public typealias Result<T> = T | Exception; // Result type

Although related, Union and Intersection types can be pursued separately. In my opinion, Union types will be more useful and hence should be looked into at first. What can be the downsides of Union and Intersection types? Let's discuss.

[Richiban]

Well, they're awesome in Typescript!

For a good example of how the syntax plays with a more C-style language (like C#), look at the docs for Ceylon (https://ceylon-lang.org/documentation/1.3/tour/types/). It has all the compiler support for union / intersection types but with a syntax much closer to C#'s.

One of the unexpected benefits I saw of union types is that you can now enumerate a tuple. Normally you can't do that because the types are heterogeneous but with union types Tuple<int, string> would appear to implement IEnumerable<int|string>, and Tuple<int, int, int, int> simply collapses down to IEnumerable<int>.

Types now have the same behaviour as sets when you apply the union or intersection operations such as commutativity, associativity etc. For example, A | B | A is the same as A | B.

[huoyaoyuan]

Quite confused by the usages.

Keep in mind that C# is an IL-level strongly-typed language. For example, if (result is short|int|long number), what should be the type of variable result? Can only be a boxed one.
When doing pattern match on it(and the same as the example of exception), consider the occasions:

• If there's looking-same things, the compiler must generate different code for each path, like the JIT compiler does for value types. This is including same name methods without implementing the same interface.
• If there's only "token"-same things, for example applying on part of things implementing an interface, the compiler should jump to the same code from different entries, and use the interface for the type.

There's quite different logic for looking-same occasions, so I think this would better be a sugar for compiler.

And for IEnumerable<int|string>: does it has any more abilities than non-generic IEnumerable? No ,it's just behaves the same with the latter, with only complaining the possible return types.

public int|Exception Method(): really a extremely bad example, because the .NET platform is getting rid of returning error code/error object.

In fact, it's good for the compiler to keep "possible types for a base-type object" as a contract for code analysis, but "intersection type" is totally incompactable for strongly-typed variable platform. You got this idea from TypeScript, but it's like an analysis system for JavaScript, the platform that variables have no type.

[qwertie]

what should be the type of variable result

The type of number is short|int|long, of course, but this does imply either boxing or some special representation, just as Nullable<int> is essentially a special representation of int|null. I think a boxed representation would be better, actually, because the fact that T? where T:struct is totally different than T? where T:class causes annoying problems in generic code, problems that could have been avoided by defining nullables as boxing. If instead we say that nontrivial union types are always reference types, the feature should integrate better with generics. This implies that int? should be different from int|null, although there could be an implicit conversion between the two. Also, maybe int|never can represent a boxed int? (never being a special type with no values, not to be confused with void which can be thought of as a size-0 type with one value)

[gulshan]

@huoyaoyuan I think this simple rule I mentioned mitigates most of your concerns-

So, we can go with the notion- "Union is only for non-interface types(classes, structs etc) while Intersection is only for interfaces."

I myself is not yet sure about the usefulness of union types as return types of methods. I would not support it in the first phase, if union types are introduced. I mentioned it as a possibility nevertheless.

[Richiban]

I think that union types are the natural next step after Tuples. If a Tuple<string, int> can be thought of as the Cartesian product of the two sets string and int it makes perfect sense to support the union of the two sets as well.

Intersections are interesting but probably not particularly useful (at least I can't think of many uses right now), but it may be the case that by implementing union types the intersection types will naturally follow.

Again, to see the value of these new type expressions, I recommend reading the docs of the Ceylon language.

[sdedalus]

We were just using Intersection today in a TS project. We knew the result of a function had to support two particular interfaces. one interface encapsulates a third-party value that we need to track at leaf nodes only and the other encapsulates required information for mapping between the structures and display used for all nodes. Rather than introduce yet another interface that does nothing but inherits from two other interfaces we just used the intersection as the return type. It was cleaner and fit the exact requirements of the function consumers. This might not be enough to justify the future in C# but it was a pleasant experience to use in TS. It does seem though that if this was an interface only intersection additional interface types could be generated at compile-time and applied to the classes or new proxy types could be generated that support all required interfaces for the intersection.

[JoergWMittag]

@Richiban wrote:

Intersections are interesting but probably not particularly useful (at least I can't think of many uses right now), but it may be the case that by implementing union types the intersection types will naturally follow.

There's a somewhat famous (at least in the Scala community) article by Miles Sabin, showing how to implement union types (which Scala doesn't have) using intersection types (which Scala does have) by virtue of the Curry-Howard-Isomorphism and DeMorgan's Laws. Since both the Curry-Howard-Isomorphism and DeMorgan's Laws "work in both directions", I wouldn't be surprised to learn that once C♯ gets union types, intersection types could be implemented in a similar fashion anyway, so one might just add them to the language anyway.

By the way, intersection types are used all over the place in Scala.

[qwertie]

DeMorgan's Laws require negation. Does Scala have negation types? That would be very interesting; even TypeScript doesn't have those. Not sure where this Curry–Howard correspondence fits in... (btw that link seems broken atm)

[contactomorph]

I think TS has negation type given that it has a bottom type never. If I'm correct, the negation of type T is type (item: T) => never

[weitzhandler]

I prefer this style.

[gulshan]

I would like to know some opinion from everyone about my proposal-

Union is only for non-interface types(classes, structs etc) while Intersection is only for interfaces.

How much does it fits with usage of union and intersection types already in use in other languages?

[Richiban]

@gulshan I don't think that's a feature that makes sense; you should be able to union or intersect any two types you wish.

As to whether it's technically possible: I don't know. There might be some implementation detail that leaks through in the fact that you can't perform these operations on all type types (?).

The only two languages I know of that support union & intersection are Typescript and Ceylon; neither of them place any restriction on what types are supported.

For example, this should make perfect sense:

public IEnumerable<string>|string GetSomeStrings()
{
	// ...
}

[Richiban]

The other really nice thing about union types is they give you a great way of representing null--by giving the literal null its own type:

public interface IPersonRepository
{
	Person|null Retrieve(PersonId personId);
}

[jnm2]

@Richiban I know it is incredibly nice! TypeScript has its flaws, but it keeps making me jealous as I watch it just nailing concept after concept that could never become part of C#.

[mattwar]

Life is easier in TypeScript where you only really have one actual type in the type system (excluding a few primitives) and everything else is window dressing.

You could do the same with C#, but you'd have to erase all the unions and simply have the type object everywhere. That means always boxing all the struct types. That means the type int | string would always carry the int's around boxed.

[douglasg14b]

The thing holding C# back in this regard is that it's strongly typed on the JIT level. Which means, under the current design constraints, if we want more flexible typing in design-time land, it has to be built out in runtime-land as well.

TypeScript isn't held back by this, as it exists entirely at design-time.

If C# could introduce design-time only type augmentation like TS, then it would become much more palatable into the future.

[Richiban]

@mattwar

Why not secretly lift the type in question into an Either<T1, T2> struct? This way code would be both backwards compatible and performant and the syntax of the language would be able to consume such a type as if it was a real union.

[tpetrina]

Can we then finally get the following:

public interface IOperation
{
    IDisposable & IObservable Start();
}

[gulshan]

@Richiban The union example was nice. Any use of intersection types for classes you can think of in C#?

[amis92]

@gulshan I think that @tpetrina 's post above has a good intersection example.

[stephen-hawley]

This is an important feature for swift interop.
Swift has the protocol composition type, which is a: p1 & p2 & p3 with means that a adopts all of the protocols p1, p2 and p3. In modeling this, it can be done for parameters using generics:

public void SomeMethod<T>(T a) where T: P1, P2, P3 { /* ... */ }

This works for arguments because the caller owns the type of T. It does not work for return values because the callee owns the type of the return type so it can't presently be expressed in C#.

[daiplusplus]

It sort-of can, if you make the return-type a generic-parameter and have the caller provide a factory method... and don't mind the fact that TReturn still needs to be implemented in a concrete type somewhere...

public TReturn SomeMethod<T,TReturn>(T a, Func<FactoryArg,TReturn> factory)
    where TReturn : I1, I2, I3
{
    // do stuff
    TReturn ret = factory( someFactoryArg ); // `FactoryArg` doesn't have to be a generic type parameter.
    return ret;
}

or if the interfaces are such that TReturn is mutable and allows the object to be initialized after it's constructed then that's also an option (though I'm really not a fan of this approach: if an object can be in a incomplete state after construction then that's a bad class design, imo).

public TReturn SomeMethod<T,TReturn>(T a)
    where TReturn : I1, I2, I3, new()
{
    // do stuff
    TReturn ret = new TReturn();
    ret.Initialize( ... );
    return ret;
}

[vgb1993]

I would love having this feature available in c#. It makes your life easyer.

[JohnGalt1717]

I'd love to see function definitions like this: public (int|byte|string) bar() {...}

And consume like this:

var foo = bar();

switch(foo) {
string s => ...;
byte b => ...,
int i => ...
}

And compile time error if the definition of bar adds or removes type definitions as acceptable return types and it isn't handled in the switch.

[martinrhan]

There have been a lot of discussions about this and I found them very useful. But when will this language feature get implemented?

[333fred]

I'm not certain who the "we" here is, but it isn't the language design team.

[airbreather]

I haven't seen mention of this use case from a quick Ctrl-F on this thread, so I wanted to jot it down here. If I'm overlooking some robust solution that's viable with today's tools and provides a similar quality of user experience, please reply here and let me know (selfishly, it would help with the actual specific use case in an internal utility that brought me to this thread 😈).

IProgress<T> is part of the set of best-practices for asynchronous methods following the TAP pattern. Currently, however, it's somewhat annoying to use on both the producer and the consumer sides when there's a non-trivial API with multiple distinct stages:

• Whoever adds an IProgress<T> parameter will need to design their T type parameter to be something that can provide different data for different parts of the routine... or else they need to accept multiple IProgress<T> instances or split up what's logically a single routine into multiple calls.
• Whoever calls such an API method needs to understand all the different subtypes of T (or use some custom flavor of pattern matching) in order to get access to the different potential relevant data members that the specific instance might carry. There is no practical (standard) way for the development environment to help the caller see all the different types of specializations it might carry.
  • If the base type exposes an enum value to indicate which state it's in, then there are built-in compiler warnings that can help the caller make sure that they've handled all possible states... but they have to do something extra to actually unpack any extra state-specific data.
  • If the expected thing is just for the caller to use a switch on the base instance with "type patterns", then unless the creator of that API added some custom analyzers to help use it, there is very little that the system can do to help the caller ensure that they've checked all the different possibilities.

Having union types fully integrated into the type system would significantly improve my experience in this case. The type parameter could be something that expresses that the report is going to provide any one of the following:

• OperationStarted (without extra data)
• StageOneStarted (without extra data, or maybe with data indicating the number of elements to be processed during stage 1)
• StageOneProcessedDataElement (with some data to identify the data element that was being processed)
• (and so on...)

Whenever the caller opts-in to passing in something useful for their IProgress<T> parameter, they need to provide an instance of some type that has acknowledged the entire set of possible messages that could be received when declaring that it implements the corresponding interface, and if that implementation winds up doing a switch over the report data instance, I imagine that the development environment could be set up to make it hard to unintentionally miss handling some message by accident.

[jnm2]

I played around with a structured progress exchange type at https://github.com/Techsola/StructuredProgress but haven't found a regular use for it.

[martinrhan]

I would like to mention another important utility of the feature.

public class MyBase{
  //something here
}
public interface IWrapper<out T>{
    public T Object {get;}
}
public class Wrapper<T> : MyBase, IWrapper<T>{
    public T Object {get;set;}
}
public class AnotherBase{
}
public class AnotherDerivedA : AnotherBase{
}
public class AnotherDerivedB : AnotherBase{
}

For the example above, I want to use covariance and store the Wrapper<AnotherBase>s into a List.
But how should I do it? What should the generic argument of the List be?
If I choose List<Wrapper<AnotherBase>>, I cannot benefic from covariance. I can only add what's exacly Wrapper<AnotherBase>, cannot add Wrapper<AnotherDerivedA> or Wrapper<AnotherDerivedB>.
If I choose List<IWrapper<AnotherBase>>, I can benefit from covariance. IWrapper<AnotherDerivedA> and IWrapper<AnotherDerivedB> can be added into the List like they are child class of IWrapper<AnotherBase>. However, I loss the members of MyBase.
Similarly, if I choose List<MyBase> I loss members of IWrapper<AnotherBase>.
Without using explicit type casting, the only way to do it in nicely typed manner is intersection type. That is, MyBase & IWrapper<AnotherBase>.
By List<MyBase & IWrapper<AnotherBase>>, we can add any instance of any type that can be assigned to both MyBase and IWrapper<AnotherBase>. Which includes Wrapper<AnotherDerivedA> and Wrapper<AnotherDerivedB>. This approach also reserved members of both MyBase and IWrapper<AnotherBase> without using type casting.

[TahirAhmadov]

I posted this comment elsewhere but since thread was created earlier, I'm posting it here to - not meaning to spam at all.

One approach without runtime support but with strong typing is creating multiple parameters - one for each requested type, in metadata/IL, with special attributes. Then the language can interpret it and "make it look" like it's an intersection type:

void Foo(IDog & ICat dogCat)
{
  dogCat.Bark();
  dogCat.Meow();
}
var dogCat = new DogCat();
Foo(dogCat);
// becomes:
void Foo([IntersectsWith(nameof(dogCatCat))] IDog dogCatDog, [IntersectsWith(nameof(dogCatDog))] ICat dogCatCat)
{
  dogCatDog.Bark();
  dogCatCat.Meow();
}
var dogCat = new DogCat();
Foo(dogCat, dogCat);

Same idea for locals and fields.
Things like get-properties and method return values are not possible this way, though. To solve that, tuple type can be used:

// becomes:
void Foo([IntersectionType] (IDog dogCatDog, ICat dogCatCat) dogCat)
{
  dogCat.dogCatDog.Bark();
  dogCat.dogCatCat.Meow();
}
var dogCat = new DogCat();
Foo((dogCat, dogCat));

Obviously this approach has its own downsides, such as messy signatures. On the upside, languages which don't support this can just pass the same value twice when calling a method like this.

[daiplusplus]

Intersections of interface-types are already supported though (as void Foo<TDogCat>( TDogCat dogCat ) where T : IDog, ICat).

I don't personally think .NET interface intersections have much inherent utility given if a type T satisfies IDog, ICat then 90% of the time you can remove generics and use T directly. (Another scenario is preventing the boxing of struct implementations of interfaces, but that's kinda niche already).

[TahirAhmadov]

Yes, but that's only viable for method parameters and return values; this doesn't work with properties, fields, locals, etc.

[Aloento]

same #6352

[GeeLaw]

Forwarded from #6352, originally in reply to @TahirAhmadov.

Already mentioned above is to use generics to handle intersection-typed parameters, but the previous solution wasn't fully performant. The right solution is

// Intersection of interfaces.
void Foo<T12>(T12 t12) where T : class, I1, I2
{
}
void Foo<T12>(ref T12 t12) where T : struct, I1, I2
{
}
// Intersection of class and interface.
// T1 is the name of a class.
void Bar<T12>(T12 t12) where T : T1, I2
{
}

For a field of type T1 & T2, the struct scenario above will not apply. If you know the field is of TStruct : struct, T1, T2, you should type the field as TStruct. The other scenario is that the field should be capable of holding any reference that is both T1 and T2. This can be done using a generic struct that wraps a reference:

// For holding a reference-typed field. More arities can be added.
public readonly struct Intersection<T1, T2>
  where T1 : class
  where T2 : class
{
  public readonly object Target;

  public T1 AsT1
  {
    [MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
    get { return Unsafe.As<T1>(Target); }
  }

  public T2 AsT2
  {
    [MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
    get { return Unsafe.As<T2>(Target); }
  }

  [MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
  private Intersection(object target)
  {
    Target = target;
  }

  [MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
  public static Intersection<T1, T2> Create<T12>(T12 t12) where T12 : class, T1, T2
  {
    return new Intersection<T1, T2>(t12);
  }

  [MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
  public static Intersection<T1, T2> Copy<T12>(T12 t12) where T12 : struct, T1, T2
  {
    return new Intersection<T1, T2>(t12);
  }

  [MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
  public static Intersection<T1, T2> Cast(object t12)
  {
    return new Intersection<T1, T2>((object)(T2)(object)(T1)t12);
  }

  [MethodImpl(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
  public static Intersection<T1, T2> As(object t12)
  {
    return new Intersection<T1, T2>((((t12 as T1) as object) as T2) as object);
  }
}

In reply to a comment by @TahirAhmadov

On the idea itself - it's actually great and I think is the right solution - granted the "casting" can be reduced at some point so that during actual execution, it's zero-cost.

The above implementation is zero-cost when all the annotated optimizations are in force. Unsafe.As simply returns the reference without any run-time type checking (therefore, Unsafe.As<string>((object)0) could return a boxed int typed as string, thus Unsafe; the docs makes Unsafe.As<T>(o) well-defined only if (T)o would succeed).

---

It is very important to have a safe, in particular, thread-safe, implementation. The above implementation is not known to be safe as far as C# language spec is concerned. However, it is safe for most implementations of C# (and can be made so if it becomes part of C#, so that any non-guarantee of user code does not apply):

1. Presumably, the layout of Intersection<T1, T2> is identical to a bare reference.
2. References do not tear, meaning that overwriting Intersection<T1, T2> is atomic.
3. If only public members are used by an outsider, then Target always holds a reference that is both T1 and T2 (or null), so the Unsafe.As calls are well-defined.

In contrast, a safe implementation of discriminated union with a single underlying reference field and Unsafe.As is much more difficult, because the tag (say an integer indicating whether it is Class1 or Class2) and the reference could be torn.

[HaloFour]

@TahirAhmadov

// made up syntax to denote storing different fields in the same memory

That would be StructLayoutAttribute and FieldOffsetAttribute, and it's been supported since C# 1.0. But there are runtime limitations, especially since reference types can't overlap without impacting GC. For those cases the code emitted could potentially take a different approach, like using an object field for multiple reference types and using the tag to determine the type and cast appropriately, etc.

[TahirAhmadov]

That would be StructLayoutAttribute and FieldOffsetAttribute, and it's been supported since C# 1.0.

My understanding is that those only apply when struct is exported to unmanaged code, and doesn't change what happens in managed memory.

But there are runtime limitations, especially since reference types can't overlap without impacting GC. For those cases the code emitted could potentially take a different approach, like using an object field for multiple reference types and using the tag to determine the type and cast appropriately, etc.

You're probably right, I'm not too sure about this, however, it could still cause the same type of problem @GeeLaw was talking about above: the object field has a IConvertible, the tag is set to the other option, then getting the IEnumerable produces unexpected results.
PS. To his point: if the implementation goes with (IConvertible)_backingObjectField, it would be an invalid cast; with Unsafe, it would be some real bad stuff later on; so that's a decision to be made when DUs are tackled. However, the same can happen with unmanaged fields, and there is no solution currently to keeping the struct DU "valid" in a thread-safe manner that I know of; just a choice of "always cast, accept the extra cost, and fail right away", or "always do Unsafe, save on the casting cost, but fail in a worse way later on".

[HaloFour]

@TahirAhmadov

My understanding is that those only apply when struct is exported to unmanaged code, and doesn't change what happens in managed memory.

It does affect managed memory, this is why it's dangerous and can't be applied to reference types. You can try this today by making a simple struct that have two int fields that overlap, if you assign one field the other field immediately reflects the value. You can overlap two ints and a long, etc.

[TahirAhmadov]

You are right! Weird, the documentation says "unmanaged" and I always assumed it's only for WinApi calls and such. I never had to use this, so please forgive my ignorance.

[acaly]

StructLayoutAttribute doesn't support generic types, which is a big limitation.

If we add union types we will face the same problem. If we share the memory, the GC may not be able to identify reference slots.

[DavidArno]

I've been using unions a lot recently and one of the conclusions I've reached echoes what @JohnGalt1717 said a year ago: ad-hoc unions are an incredibly useful feature and they complement tuples really nicely.

Tuples serve a way of defining a collection of disparate values at the point where they are returned from a function:

(int v1, float v2, string v3) SomeFunc() => ...

And this same "define at the point of use" works nicely with DUs too in a lot of cases, especially when passing values around internally within an assembly:

(int | float | string) SomeOtherFunc() => ...

Generally I've found that I'm never interested in the container type of such DUs as the returned value is normally immediately handled with some form of pattern matching.

I'm not saying there's no need for defining formal union types, especially if the same type is used in multiple places. But these ad-hoc DUs certainly have a place in the language too I feel.

[MuleaneEve]

Here is a real-world example where an intersection of interfaces would be nice:

https://github.com/dotnet/maui/blob/24df7559557b5d7ebd727df7cc08f745b90d0f32/src/Controls/src/Core/Handlers/Items/Android/ItemsSources/ObservableItemsSource.cs#L14

This class constructor takes as parameter an object that must implement IEnumerable & INotifyCollectionChanged.
However, there is no way to explicitly express that as-is.

Currently, one way to make it explicit would be to make this class generic. But that will lead to all the upstream classes needing to also have that generic type, which is often not feasible.

By the way, this could also be done with a feature like shapes (although it would be more verbose).

[Richiban]

Does anyone with knowledge of the JVM and associated languages know how Ceylon and Scala are able to implement union and intersection types without modifications to the runtime?

[HaloFour]

Scala fakes it. The bytecode signature of the method only reflects one of the types specified in the Scala signature and the method body assumes that it can cast freely to the other interface. Scala uses a lot of its own external metadata which is not understood by other JVM-based languages.

  // access flags 0x1
  // signature (LGrowable<Ljava/lang/String;>;)V
  // declaration: void f(Growable<java.lang.String>)
  public f(LGrowable;)V
    // parameter final  x
   L0
    LINENUMBER 21 L0
    ALOAD 1
    CHECKCAST Resettable
    INVOKEINTERFACE Resettable.reset ()V (itf)
   L1
    LINENUMBER 22 L1
    ALOAD 1
    LDC "first"
    INVOKEINTERFACE Growable.add (Ljava/lang/Object;)V (itf)
    RETURN
   L2
    LOCALVARIABLE this LY$; L0 L2 0
    LOCALVARIABLE x LGrowable; L0 L2 1
    MAXSTACK = 2
    MAXLOCALS = 2

Java would have no idea that this method expects a Resettable, and it would throw an exception at runtime.

[vnesterovsky]

A union type can be modelled in C# using tuples:

E.g., a union A|B can be expressed as (A? a, B? b), and a function that deals with union type may look as:

  string? f((A? a, B? b) value) =>
    value switch
    {
      _ when value.a is not null => "a",
      _ when value.b is not null => "b",
      _ => null
    };

Compiler can add a syntactic sugar around it, and to let write it a bit simpler e.g., as:

  string? f(A|B value) =>
    value switch
    {
      A => "a",
      B => "b",
      _ => null
    };

[vnesterovsky]

This will be bigger in size than a true union type.

That depends on definition of "true union type".

[Richiban]

I say that the feature can be modelled in current C# using tuples.

Not really, unfortunately. A union of A | B has two possible states: A or B. A tuple of nullables (as in your example) has four possible states: null, A, B or A and B, which unfortunately makes it rather unusable. Existing alternatives (such as the Either or OneOf types found on NuGet) at least fix this problem, making illegal states unrepresentable.

[vnesterovsky]

When I say that the feature can be modelled in current C# using tuples, it means that language has enough building blocks to implement it as a pure syntactic sugar around it. Indeed, tuple I suggested supports larger state then expected union of types.
This means that there is no need to greatly extend the language to implement the feature.

It is exactly the same story as with nullable types. Behind the scene it is a structure containing a value and a boolean indicator. One could argue that such structure may store unrepresentable states, which is illegal, yet nullable types are in use.

Please note, the goal of my comment was to show that union of types can be naturally implemented in C# but not to insist it must use tuples for implementation. This contrast to some comments that state the union of types are not natural fit to C# or IL or any other strongly typed language.

[Richiban]

I don't believe Nullable<T> allows for illegal states. Sure, in the internal structure the Value property will still have a value in the "null" case (because it has to in the type system) but this is not visible from the outside; accessing the Value property when the relevant boolean is false will result in an exception, making it safer than the tuple case.

(Sure, it would be nice if the Value property somehow wasn't there at all if HasValue is false, but the language can't do that without Discriminated Unions).

[TahirAhmadov]

@vnesterovsky

it means that language has enough building blocks to implement it as a pure syntactic sugar around it.

I'm not sure what you mean by "building blocks", but if you are referring to support from the runtime, I am positive that it already has everything needed to support DUs. So at this point, the LDT has a choice: either develop a less-than-ideal feature which (maybe??) is less up-front investment, and get stuck with it forever, or invest in the proper solution - and both of these can be worked on today from runtime support perspective. Looking at it like this, it makes little sense to spend the man-hours on less-than-ideal approach - using tuples and what-not.

[douglasg14b]

What are the thoughts on C# having an augmented design-time type system that doesn't need to be carried over to runtime?

I understand that's the primary thing holding back any improvement/modernizing of the type system. As a language it's becoming less and less palatable over time. Over time it's flipped to where .Net is propping C# as a language up, and C# is a detractor from what .Net provides.

As TypeScript has grown over the last 10 years, I've found myself enjoying C# (as a language) less and less. It's so rigid, and encourages less type-safe ways of doing things when dealing with more dynamic typings that are handled elegantly & safely in languages like TS. Multiple sources of truth is just gross.

[psxvoid]

The purpose of TypeScript is to add a feature to ECMASCript that the TC39 committee has explicitly excluded.

What you said seems equivalent to TS/JS. SharpScript may include features that Microsoft does not want to be officially supported by the language.

If the feature can be implemented with type erasure, then I don't see the point in implementing it in a separate language instead of C#.

We already have many version of C# + netstandard + dotnet 5-8. Imaging you could have an app written in C# 10+, and be able to transpile it to 7.3 - which seems to be supported by the desktop .NET Framework 4.8, or to C# 4.0 for .NET Framework 4.0. Though, I admit, integrating it in the latest version of the language may be much more feasible option.

If it can't be implemented with type erasure, then it's impossible to implement in a TypeScript-like language anyway – it will require runtime support, and that would be a very different thing than what TypeScript does: TypeScript explicitly forbids anything that requires runtime support.

Union and intersection types may not require any RTTI (depending on the goals and the implementation). But seems like, sometimes it may be much more feasible to just go around the censorship or strongly opinionated people/organizations. A transpiler could detect a feature level, and only compile SharpScript to C# when it has to. In other words any C# could be a valid SharpScript.

[HaloFour]

A transpiler would also be a subject for a completely different repository, as it would have nothing to do with the design or evolution of the C# language.

[CEbbinghaus]

Additionally, Unlike JS C# is a compiled language. This means that we do not need to write our code in C# 4 to run in .Net Framework 4.0 We merely need the IL generated by the compiler to be .Net Framework 4.0 compatible. This means transpiling to a different language version is pointless if you can spend the same amount of effort and just transpile the C# to NetFramework 4.0 IL.

None of this helps with our main goal of getting a union type into C#. Creating a whole new language for a single type feature is not pheasable and should therefore be ignored as a possibility. Much better to focus that energy on figuring out how we can make this possible within the current compiler / language so C#13 may contain it

[HaloFour]

Much better to focus that energy on figuring out how we can make this possible within the current compiler / language so C#13 may contain it

You could always fork Roslyn and take a stab at trying to implement a feature in the C# compiler itself. It's not exactly a low barrier to entry but it's probably lower than any of the other options.

Notably, type unions are something that the language and runtime teams are experimenting with right now. They had some proposals around potential encoding and have a working group that is supposed to present some runtime performance findings in the coming months. It's not that these requests are ignored, it's that language design is very hard.

[CEbbinghaus]

correct, This is far from dead and the team is well aware. My point was more that we should spend any expended energy in making it possible in dotnet today rather than fork the compiler