Proposal: Disjunction types or type expressions on generic type constraints

[fruediger]

I apologize in advance if something similar had ever been proposed before.

I would like to see something like disjunction types, at least for generic type constraints at method level.
A disjunction type thereby is a type A | B where a concrete instanciation t of A | B could be either of type A or of type B.

For type constraints this could be totally solved by using polymorphic overloading for each instanciation.
But let's have an possible example in C#:

T Add<T>(T a, T b) where T : int | double | string
{
    return a + b;
}

The compiler would then turn this into something like this:

T Add<T>(T a, T b) where T : int
{
    return a + b;
}

T Add<T>(T a, T b) where T : double
{
    return a + b;
}

T Add<T>(T a, T b) where T : string
{
    return a + b;
}

Note: The expression a + b is totally valid, because each of the types for which Foo got instanciated declare a + operator.

Regarding type members, special rules have to be defined. Only type members can be accessed which are in the intersection set of the involved types. That means disjuncting types leads to a conjunction of theire members. Also access to members has to be valid and meaningful in every case (for each instanciation):

interface IA
{
    long PropertyIAAndIB { get; }
    void MethodIAOnly();
}

interface IB
{
    bool PropertyIBOnly { get; set; }
    long PropertyIAAndIB { get; }
}

...

void Foo<T>(T t) where T : IA | IB
{
    long val = t.PropertyIAAndIB; // OK: both IA and IB declare a property named PropertyIAAndIB

    t.MethodIAOnly()              // ERROR: only the interface IA declares a member MethodIAOnly()
}

interface IA
{
    long PropertyIAAndIB { get; }
    void MethodIAOnly();
}

interface IB
{
    bool PropertyIBOnly { get; set; }
    int  PropertyIAAndIB { get; }
}

...

void Foo<T>(T t) where T : IA | IB
{
    var val = t.PropertyIAAndIB;  // OK: the compiler inferences the type of the variable val correctly for each instanciation of Foo

    long val = t.PropertyIAAndIB; // OK: even if this is the instanciation of Foo for type IB, the value of the property can be implicitly converted from int to long

    int val = t.PropertyIAAndIB;  // ERROR: if Foo is the instanciated for type IA, the type of the property is long which cannot be implicitly converted to int
}

interface IA
{
    long Test { get; }
}

interface IB
{
    long Test();
}

...

void Foo<T>(T t) where T : IA | IB
{
    var test = t.Test // OK, BUT this could be a erroneous point, since test is of type System.Int64 for the instanciation for type IA 
                      // and of a delegate type for type IB (Test is declared as a method in IB)
}

Disjunction types could additionally supplemented by conjuction types. Let A & B be the conjunction of type. Conjunction means nothing else than, if t is of A & B, then t needs to be of type A while also needs to be of type B. Historically, this is the , operator in C#. So & and , could be used synonymously.
Together with disjunction types and parentheses this forms a type expression syntax.

To understand type expression on generic constraints, each type expression has to be transformed to its disjunctive normal form (DNF) with the application of the usual rules of logical expressions.

So the type expression (A | B) & C | D could be also expressed as (A | B), C | D and can be transformed to its DNF (A & C) | (B & C) | D which also could be expressed as (A, C) | (B, C) | D. Where , has the usual meaning of C# generic type constraints.

A possible C# example:

class A { ... }

interface IB { ... }

interface IC { ... }

class D { ... }

...

void Foo<T>(T t) where T : (A | IB) & IC | D
{ ... }

With the rules explained above the compiler would turn this into:

void Foo<T>(T t) where T : A, IC 
{ ... }

void Foo<T>(T t) where T : IB, IC
{ ... }

void Foo<T>(T t) where T : D
{ ... }

However, this leads to a new source of error. A CLR type may not have two concrete base classes. But that's a usuall error when working with generics.

class A { ... }

interface IB { ... }

interface IC { ... }

class D { ... }

class E { ... }

...

void Foo<T>(T t) where T : (A | IB) & (E | IC) | D
{ ... }

Would be turned to

void Foo<T>(T t) where T : A, E // ERROR: A and E are both non-interface reference types

In conclusion, type expressions do not have to be concretely represented in any way. They can be achieved completely using code transformations by the compiler. So they just need to be added to the language as syntactic sugar.

At the moment I'm not sure, if these type expressions or at least disjunctions types are also applicable to generic type constraints at type declaration level. But that would be also very nice.

Finally, I apologize for my bad language, but English is not my native language.

[yaakov-h]

#399?

[gafter]

You've proposed a solution to a problem. A different, more general solution to the same problem that does not require CLR support (this one does require CLR support) is type classes. See #110 .

[jrmoreno1]

Is the reason this would require CLR support due to the fact that the compiled dll might be referenced by a compiler that doesn’t understand what is being done?