[Proposal] Implicit Type Parameters for Value- and ReferenceTypes

[a-usr]

Preamble

At the time of writing this I was unable to find a proposal quite like my Idea, so I decided to write this myself. If such a Feature or Concept already exists, please do tell me

Intro

Ladies and Gentlemen (and people of other genders),
Today I would like to draw your attention to a little Idea of mine, which, if implemented, could come in quite handy!

You see, sometimes we might want to create a type wich can represent two or more different types! Sounds quite easy right? And honestly, it should be! So lets grab an example!

using System.Diagnostics.CodeAnalysis;

public struct Either<TLeft, TRight> 
{
  private readonly TLeft? left;
  private readonly TRight? right;

  private readonly bool isRight;

  public static Either<TLeft, TRight> Left(TLeft left) => new(left, default, false);
  public static Either<TLeft, TRight> Right(TRight right) => new(default, right, true);

  public Either(TLeft? Left, TRight? Right, bool isRight)
  {
    this.left = Left;
    this.right = Right;
    this.isRight = isRight;
  }

  public bool IsRight() => isRight;
  public bool IsLeft() => !isRight;

  public bool getRight([MaybeNullWhen(false)] out TRight right)
  {
    right = this.right;
    return isRight;
  }

  public bool getLeft([MaybeNullWhen(false)] out TLeft left)
  {
    left = this.left;
    return !isRight;
  }
}

Here we have a Type wich represents either a value of type TLeft or TRight. Seems easy enough.
But wait, what about our Glorious Pattern matching?

Pattern matching

Using the switch expression (Introduced in C#8) and the is operator we can perform pattern matching.

Patterns that we can match against include, but are not limited to:

• var Patterns
• Property Patterns
• Logical Patterns
• Type Patterns
• Positional Patterns

(as described in the C# Documentation)

As you might have noticed, the last two Patterns mentioned are highlighted. That is because these two are pretty interesting to us.

Type Patterns

As the name suggests, this Pattern allows us to check wether the Runtime Type of an object is compatible with a different Type.

Here a Example:

internal class Program
{

  private static void Main(string[] args)
  {
    string obj = "Hello World";
    object box = obj;

    if (box is int)
    {
      int num = (int)box;
      Console.WriteLine("Number is ", num, "!");
    }
    else if (box is string)
    {
      string str = (string)box;
      Console.WriteLine("String is ", str, "!");
    }
  }
  
}

Breaking down this example, we are effectively getting a variable box of an unknown Type (Lets just pretend that we got the value of box from a method call), and then we are matching against a couple of possible types that box could have, treating box differently depending on the type that we actually find.

Positional Patterns

Using a Positional Pattern, we can Deconstruct an object, and compare against or extract its contents.

Here a quick Example, taken directly from the msl Documentation:

public readonly struct Point
{
    public int X { get; }
    public int Y { get; }

    public Point(int x, int y) => (X, Y) = (x, y);

    public void Deconstruct(out int x, out int y) => (x, y) = (X, Y);
}

static string Classify(Point point) => point switch
{
    (0, 0) => "Origin",
    (1, 0) => "positive X basis end",
    (0, 1) => "positive Y basis end",
    _ => "Just a point",
};

In this example the point is only compared against constant values. By altering this Example we can extract the x and yvalues like so:

public readonly struct Point
{
    public int X { get; }
    public int Y { get; }

    public Point(int x, int y) => (X, Y) = (x, y);

    public void Deconstruct(out int x, out int y) => (x, y) = (X, Y);
}

static string Classify(Point point) => point switch
{
    (0, 0) => "Origin",
    (1, 0) => "positive X basis end",
    (0, 1) => "positive Y basis end",
    (int x, int y) => "Just a point with the coordinates (" + x.ToString() + ", " + y.ToString() + ")",
};

I think this example doesn't need any more explanation, so lets continue.

How can we use those two Patterns?

You probably are corious why I explained those two Pattern types just now, so before I show you why we want to use them, let me give you another Example, this time about how we can combine these two Patterns:

  public readonly struct Point2d
  {
    public int X { get; }
    public int Y { get; }

    public Point2d(int x, int y) => (X, Y) = (x, y);

    public void Deconstruct(out int x, out int y) => (x, y) = (X, Y);
  }
  
  public readonly struct Point3d
  {
    public int X { get; }
    public int Y { get; }
    public int Z { get; }

    public Point3d(int x, int y, int z) => (X, Y, Z) = (x, y, z);

    public void Deconstruct(out int x, out int y, out int z) => (x, y, z) = (X, Y, Z);
  }

  static string Classify(object point) => point switch
  {
    Point2d (0, 0) => "Point2D: Origin",
    Point2d (1, 0) => "Point2D: positive X basis end",
    Point2d (0, 1) => "Point2D: positive Y basis end",
    Point2d (int x, int y) => "Point2D: Just a point with the coordinates (" + x.ToString() + ", " + y.ToString() + ")",

    Point3d (0, 0, 0) => "Point3D: Origin",
    Point3d (1, 0, 0) => "Point3D: positive X basis end",
    Point3d (0, 1, 0) => "Point3D: positive Y basis end",
    Point3d (0, 0, 1) => "Point3D: positive Z basis end",
    Point3d (int x, int y, int z) => "Point3D: Just a point with the coordinates (" + x.ToString() + ", " + y.ToString() + ", " + z.ToString() + ")",
    _ => "Not a Point2D or Point3D"
  };

As you can see, I just used Pattern matching to first determine the Type of the point, and then deconstructed the point to match against or extract its Data.

So, using this, lets redesign our Original Either<TLeft, TRight> design:

Redesign

public interface Either<TLeft, TRight>
{
  public bool isLeft();
  public bool isRight();

  public bool getLeft([MaybeNullWhen(false)] out TLeft left);
  public bool getRight([MaybeNullWhen(false)] out TRight right);
}

public struct Left<TLeft, TRight> : Either<TLeft, TRight>
{
  public readonly TLeft value;
  
  public Left(TLeft value) { this.value = value; }

  bool Either<TLeft, TRight>.getLeft([MaybeNullWhen(false)] out TLeft left)
  {
    left = value;
    return true;
  }

  bool Either<TLeft, TRight>.getRight([MaybeNullWhen(false)] out TRight right)
  {
    right = default;
    return false;
  }

  bool Either<TLeft, TRight>.isLeft() => true;

  bool Either<TLeft, TRight>.isRight() => false;

  public void Deconstruct(out TLeft left) => left = value;
}

public struct Right<TLeft, TRight> : Either<TLeft, TRight>
{
  public readonly TRight value;
  
  public Right(TRight value) { this.value = value; }

  bool Either<TLeft, TRight>.getLeft([MaybeNullWhen(false)] out TLeft left)
  {
    left = default;
    return false;
  }

  bool Either<TLeft, TRight>.getRight([MaybeNullWhen(false)] out TRight right)
  {
    right = value;
    return true;
  }

  bool Either<TLeft, TRight>.isLeft() => false;

  bool Either<TLeft, TRight>.isRight() => true;
  
  public void Deconstruct(out TRight right) => right = value;
}

Great, now we can use Pattern matching to get our Left or Right value!
But lets take a look at the syntax:

internal static class Program
{
  public static void Main(string[] args)
  {
    Either<int, string> either = new Left<int, string>(5);

    if (either is Right<int, string> (string text)) 
    {
      Console.WriteLine("Text is: " + text);
    }
    else if (either is Left<int, string> (int num)) 
    {
      Console.WriteLine("Number is: " + num);
    }
  }
}

As you can see, even though e.g. Left only needs to know TLeft and not TRight we need to supply Tright anyways!

Wouldn't the following be much nicer?

internal static class Program
{
  public static void Main(string[] args)
  {
    Either<int, string> either = new Left<int>(5);

    if (either is Right<string> (string text)) 
    {
      Console.WriteLine("Text is: " + text);
    }
    else if (either is Left<int> (int num)) 
    {
      Console.WriteLine("Number is: " + num);
    }
  }
}

So lets try to change our code accordingly:

public interface Either<TLeft, TRight>
{
  public bool isLeft();
  public bool isRight();

  public bool getLeft([MaybeNullWhen(false)] out TLeft left);
  public bool getRight([MaybeNullWhen(false)] out TRight right);
}


public struct Left<TLeft> : Either<TLeft, ???> // What do we supply to our Interface?
{ [...]

Enter Implicit Type Parameters

Imagine the following: What if the CLR could automatically infer the omitted type depending on the objects useage?

Here is the concept:

public interface ITypeWithManyTypeParameters<TA, TB> 
{
  public TA MethodA();
  public TB MethodB();
  public TB MethodC();
}

public class TypeWithLessTypeParameters<TA> : ITypeWithManyTypeParameters<TA, var TB> // Concept Implicit Parameter declaration using var [Parameter Name]
{
  private TA VarA; // Valid
  private TB VarB; // Invalid, TB Isnt known to this class

  public TA OwnMethodA() // Valid
  {
    return default(TA);
  }
  public TB OwnMethodB() // Invalid, TB Isnt known to this class
  {
    return default(TB);
  }

  public TA MethodA() // valid
  {
    return default(TA);
  }
  public TB MethodB() // Invalid, TB Isnt known to this class
  {
    return default(TB);
  }
  TB ITypeWithManyTypeParameters<TA, var TB>.MethodC() // valid, since MethodC is explicitly implemented
  {                                                // (wich means that the method can only be called
    return default(TB);                            // if the object is boxed to ITypeWithManyTypeParameters<TA, TB>)
  }                                                // TB can be inferred from the Type that it is boxed to
                                                   // and all that MethodC has to do is return a compatible object

}

Using Inplicit Type Parameters, TypeWithLessTypeParameters<TA> is compatible with ITypeWithManyTypeParameters<TA, any>,
where any represents every type that satisfies the constraints on TB set by ITypeWithManyTypeParameters<TA, TB> ,or maybe even TypeWithLessTypeParameters<TA>

Outro

If you have Any Questions, Ideas, additional pieces of Information, or Critique, please feel free to ask or tell!

[HaloFour]

Just because it's featured so heavily in your use case: #113

I also think bottom types may work in this case as well: #538

This is how Scala handles such cases, e.g. None extends Option[Nothing]. Although not for Either[L, R], presumably because Left still needs to know what the other type parameter is in order to implement the required members.

[a-usr]

I also think bottom types may work in this case as well: #538

public interface Either<TLeft, TRight>
{
 public bool isLeft();
 public bool isRight();

 public bool getLeft([MaybeNullWhen(false)] out TLeft left);
 public bool getRight([MaybeNullWhen(false)] out TRight right);
}

public struct Left<TLeft> : Either<TLeft, bottom>
{
 public readonly TLeft value;
 
 public Left(TLeft value) { this.value = value; }

 bool Either<TLeft, bottom>.getLeft([MaybeNullWhen(false)] out TLeft left)
 {
   left = value;
   return true;
 }

 bool Either<TLeft, bottom>.getRight([MaybeNullWhen(false)] out bottom right)
 {
   right = default;  // since bottom cant have any instances, what is the default? null?
   return false;
 }

 bool Either<TLeft, bottom>.isLeft() => true;

 bool Either<TLeft, bottom>.isRight() => false;

 public void Deconstruct(out TLeft left) => left = value;
}

And a different example use case in wich bottom would not work (Im not saying youre wrong, Im just saying that bottom cant be used in the same way as Implicit Type Parameters):

public interface IType<T>
{
 public List<T> NewListFrom<U>(U value) where U: T;
}

public class Type : IType<var T>
{
 List<T> IType<var T>.NewListFrom<U>(U value) where U: T
 {
  return new List<T>(){ value };
 }
}

[HaloFour]

This is probably why languages like Scala, which do have a bottom type Nothing, still have Left[L, R] and Right[L, R], that other type parameter is still required to implement all of the rest of the members.

[a-usr]

Just what I was thinking 👍Also that comment was meant as an actual question. Do you think the default for bottom would be null? Or wouldn't there be a default?