LDM Notes for March 8th, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-03-08.md

Agenda

• Discriminated Unions
• Limited Breaking Changes in C#

[agocke]

List<(A | B)> cannot be freely converted to List<(A | B | C)>

Nit: I think you mean array or IEnumerable since lists are invariant

[yaakov-h]

Continuing in today's LDM theme of light, easy, non-controversial topics

😂

The last few LDM (notes) have all been quite exciting to see, and quite interesting.

[TahirAhmadov]

I haven't thought through this too too much, so don't consider this to be a proposal, but with the disclaimer, why don't we do this?

struct OneOf<T1, T2>
{
  // new type of operator
  public static check operator bool(OneOf<T1, T2> operand, out T1? result)
  {
    if(operand.HasFirst) { result = operand.First; return true; }
    return false;
  }
  public static check operator bool(OneOf<T1, T2> operand, out T2? result)
  {
    if(operand.HasSecond) { result = operand.Second; return true; }
    return false;
  }
  // ....
}
OneOf<int, string> x = 123;
if(x is int i) { ... }
if(x is string s) { ... }

// additional scenarios allowed by the new "check" operator
implicit extension for String
{
  public static check operator bool(string operand, out int result) => int.TryParse(operand, out result);
}
string str = "123";
if(str is int i) { ... }

explicit extension NumberString for String 
{ 
  public int CompareTo(NumberString other) { ... } 
  public static check operator bool(string operand, out NumberString result) { ... }
}
string str = "123";
if(str is NumberString numStr) { ... }

Basically, the "one of many existing types" feature is just a new type in the BCL, and it uses a new type of operator which allows is operator to perform the necessary check. Thoughts?

[TahirAhmadov]

Please take a look, I added to my post, it can also make "roles" (explicit extensions) easy to use.

[HaloFour]

@TahirAhmadov

Actually, even without an analyzer, if you have 2 operators like that, both with out string? result, overload resolution will fail, thus generating a compilation error, which is enough of a deterrent.

Not in a generic method, if T1 or T2 can both be string, the compiler is already fine with overload resolution in those cases.

I'm in the camp that type unions (outside of closed type hierarchies) are too gnarly to retrofit into the runtime and too messy to try to emulate in the language, and given that tagged unions covers nearly all of those use cases I honestly don't see much point in pursuing them. I think having a blessed DU like OneOf<...> to support those cases is fine, but the more the language tries to paper over the tagged union under the covers the more likely that the leaky abstraction will bite someone. I also think that it opens a massive can of worms to introduce type coercion into pattern matching.

[agocke]

@TahirAhmadov Try actually implementing this, i.e. listing out the fields. I think you will run into most of the problems I ran into in #7016

[TahirAhmadov]

OK to make sure I understand:

• The main work would be the enum struct ... approach - tagged unions with optional state;
• "Type unions" will just become a different syntax like (int | string) and will "trans-pile" to OneOf<int, string>, given a special generic tagged union type in the BCL in the form of enum struct OneOf<T1, T2> { First(T1), Second(T2) }

Right?

[orthoxerox]

@TahirAhmadov Type unions implemented as OneOf<,> need a lot of hacks to behave naturally, you'd want the following to be true (where =:= means "is the same type as"):

• A|A =:= A
• A|B =:= B|A
• (A|B)|C =:= A|(B|C) =:= A|B|C
• A|B =:= B if A is a subtype of B
• A|B is a subtype of C if A and B are subtypes of C

[DavidArno]

We also thought a bit about how tags will interact with pattern matching. The natural syntax we would want to use likely conflicts with type patterns: can we make that work?

I think the question has to be "how can we make that work". For union RandomAnimals { Cat, Giraffe, Tardigrade }, the POLA syntax for pattern matching has to be if (randomAnimal is RandomAnimals.Giraffe) .... Any other syntax would create so much confusion. It doesn't matter whether Giraffe is a type: it is the condition under test: x is Condition needs to become a generalised concept where that condition could be a type, a tag or an "active pattern".

And, in particular, will there be a way to declare a variable that encapsulates all the state of a particular tag?

If I have a tag union, union Shape { Square(double Side), Rectangle(double Length, double Height) }, then either I can test whether it is a Rectangle:

if (x is Shape.Rectangle) ...

or I can extract its details if it is:

if (x is Shape.Rectangle { Length: var length, Height: var height }) ...`

It doesn't seem unreasonable to insist that if I want to capture the Rectangle itself, then I must declare it as eg a record and use it within a type union.

[HaloFour]

There's nothing stopping the compiler from emitting nested structs for each tag, although it might complicate optimizing storage:

public struct enum Shape {
    Rectangle(int length, int width),
    // other members omitted for brevity
}

public struct Shape {
    private const int RECTANGLE_TAG = 0;

    private readonly int tag;
    private readonly Rectangle rectangle;

    private Shape(Rectangle rectangle) {
        this.tag = RECTANGLE_TAG;
        this.rectangle = rectangle;
    }

    // lots of stuff omitted for brevity

    public struct Rectangle {
        public int Length { get; }
        public int Width { get; }

        public Rectangle(int length, int width) {
            this.Length = length;
            this.Width = width;
        }

        public void Deconstruct(out int length, out int width) {
            length = this.length;
            width = this.width;
        }

        public static implicit operator Shape(Rectangle rectangle) => new Shape(rectangle);

        // borrowing from old design discussions around user-defined patterns
        public static bool operator is(Shape shape, out Rectangle rectangle) {
            if (shape.tag == RECTANGLE_TAG) {
                rectangle = shape.rectangle;
                return true;
            }
            rectangle = default;
            return false;
        }
    }
}

[agocke]

My proposal would be, everything after the tag in the tagged union would be a tuple. So you could do is Rectangle x and x would be a tuple (int Length, int Width).

[DavidArno]

My proposal would be, everything after the tag in the tagged union would be a tuple. So you could do is Rectangle x and x would be a tuple (int Length, int Width).

Providing the ability to decompose it to a tuple would be a neat solution. I think it would be a shame if this was all that happened when pattern matterning a tagged union though. Being able to using property pattern matching on its values would be desirable too. I currently oppose @orthoxerox here as I feel for union Shape { Square(double Side), Rectangle(double Length, double Height) }, Rectangle has two values that walk and quack like properties, so it seems sensible to me to allow them to be used in a property pattern.

[HaloFour]

I think it would be nice of the cases could be treated like they were struct records. That would get you both positional deconstruction and property patterns.

As for the actual codegen, I think that depends on what the compiler can accomplish without incurring a performance penalty due to copies and whether the compiler can overlap storage efficiently.

[agocke]

Right, because tuples are created by copying there's already significant flexibility in codegen

[alrz]

Limited Breaking Changes in C#

What other past features can take advantage of this? The proposal thread mentions discards, var, nameof, and pattern operators.

Also, features like #946 can definitely get simpler if some level of break is allowed.

Would something like "covariant return types with implicit interface implementations" be considered too (as long as a fix-all could be implemented to adjust affected code)?