Added: LDM Notes for February 8th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2021/LDM-2021-02-08.md

Agenda

1. Virtual statics in interfaces
   1. Syntax Clashes
   2. Self-applicability as a constraint
   3. Relaxed operator operand types
   4. Constructors

[0x0737]

Can virtual statics be allowed in classes also? If yes, are there any plans to do it in future?

[jnm2]

From the notes:

Options 2 and 3 also have a question of how they will apply to class members. Due to the size of the changes required we may have to split virtual static members, shipping with just interfaces in the first iteration and adding class types at a later point.

[0x0737]

Sorry, missed it. Thanks.

[jnm2]

For private members, this makes perfect sense, as the concept of a virtual private method is an oxymoron: if you can't see it, you can't override it.

Nested types can see and override it. It's a common pattern to make abstract class constructors private to close the hierarchy.

[MgSam]

If we want to improve the new() constraint in the mean time, we can look at a more structural form, and users can work around the lack of additional constraints for now by using a static virtual.

I found this humorous. We've been working around the lack of either for 20 years! :)

That said, I agree that static virtual satisfies 90% of the need anyway. Since async constructors seem to be dead; static virtual is more broadly useful.

[orthoxerox]

For example, a matrix type would want to be able to add a matrix and a numeric type, and return a matrix.

Isn't that already allowed?

This breaks down with user-defined virtual operators in interfaces, however, as the type in the operator won't be the current type, it will be some type derived from the current type. Here, we naturally look at self types as a possible option.

I just don't see a use case for virtual operators. Abstract factory methods will be an incredible feature, but operators are usually syntax sugar for instance methods and virtuality is achieved via the instance method:

public interface IMagma<T> where T : IMagma<T>
{
  public static T operator +(IMagma<T> lhs, T rhs) => lhs.Op(rhs);
  protected abstract T Op(T other);
}

public record MyInt(int Value) : IMagma<MyInt>
{
  MyInt IMagma<MyInt>.Op(MyInt other) => new (Value + other.Value);
}

[FaustVX]

No, operators are static methods.

class C
{
    public static C operator +(C left, C right)
        => new C()
}

and then you can :

C c = null;
var r = c + c;

r is not null

[orthoxerox]

@FaustVX that's not what I meant. They usually delegate the actual work to an instance method. Cf framework design guidelines: "CONSIDER providing methods with friendly names that correspond to each overloaded operator."

[FaustVX]

Ah, you mean, in the class C add the Add(C other) method, and delegate the + to the Add method ?

[huoyaoyuan]

We won't block on self types being in the language

Self type will be useful for many use cases of virtual static methods.

Anyway, to be foreseeing, please discuss with BCL to design an "ultimate" replacement of current limited interfaces. We already have IComparable and IComparable<T> now. I don't want to see IStaticComparable (using self) and SComparable (shape/type class) to duplicate their features.

Do to the cost we have to implement and ship them in multiple versions, but please get a general design to avoid such duplication again.

[MrJul]

Self-applicability as a constraint

[...]
The main question here is what do we do about this? We have 2 paths:

1. Forbid interfaces with an abstract static from satisfying a constraint on itself.
2. Forbid access to static virtuals with a type parameter unless you have an additional constraint like concrete.

Option 2 seems weird here. Why would a user have constrained to a type that implements an interface, rather than just taking the interface, unless they wanted to use these methods?

I can think of a few cases where constraining instead of taking the interface directly makes sense:

1. As an optimisation to avoid boxing if the caller passes a struct that satisfies the constraint (the type itself doesn't matter).

2. 1. For helper methods acting on generic types which aren't variant interfaces:
      AddSpecial<T>(List<T> items, T item) where T : ISpecial => // do something special and add it to the list
      The expectation here is that most callers will have a strongly-typed list so Add(List<ISpecial> items, ISpecial item) isn't the most interesting choice (but can still be "for free" using the generic method).
      Example: AddExplicitInterfaceIfRequired called with T : ISymbol being ISymbol.

   2. Even if the interface isn't passed itself directly to the constraint, a derived interface (that didn't override those abstract static implementations) might. This is probably the most common case.
      Example: AddDefIfNecessary, called with T : IDefinition being IMethodDefinition or IEventDefinition.

   3. Even with available variance, you want to keep the original T in the return type or another parameter (think LINQ-like methods).
      Example:

public interface IOrderable {
    abstract static int GetSomeMetadata();
    int Order { get; }
}

class Foo : IOrderable { ... }
class Bar : IOrderable { ... }

public static IEnumerable<T> Order<T>(IEnumerable<T> values)
where T : IOrderable
    => values.OrderBy(x => x.Order);

var foos = new Foo[] { new(), new() };
var bars = new Bar[] { new(), new() };
var orderedFoos = Order(foos); // OK
var orderedBars = Order(bars); // OK
var orderedAny = Order(foos.Concat<IOrderable>(bars)); // does not compile!

Before, adding an abstract member to an interface or class had known implications: you're breaking your descendants. Callers were mostly unaffected, if someone is calling A() and B() is added, it doesn't matter.

After, adding an abstract static member can potentially source break any caller happening to fulfill a constraint with the constraint's type or a derived abstract type, even though it doesn't use the newly added member. Take the Order<T> example above: if one really wants to order those foos and bars together, it's not possible anymore, not without writing a new method. Which might not be as simple as in the example, can lead to duplicate code with the generic method, or can simply be impossible if the generic method is implemented in an external library.

If that wasn't clear already, I think option 2 is a more sensible choice ;)

[MadsTorgersen]

@MrJul these are certainly good examples of where you want to be able to pass interfaces as type arguments. In practice, I think there are interfaces that are mostly used in constraints; especially ones that take a self-like parameter like IEquatable<T> or the as-yet mythical IArithmetic. Those have virtually no value as types directly, because what do you supply as the T?

Numerics and static factories are both of this kind, and are probably the biggest scenarios (that we've thought of) for abstract members in interfaces. That at least somewhat minimizes the number of times you'd want to (or be able to) provide the interface itself as a type argument.

So all in all I'd rather make for a simpler consumption story for these interfaces and not require the "concreteness" or "classness" expressed as a separate constraint.

If in the future we were to allow static virtual members with default implementations, then we would likely also allow interfaces where all the static virtual members have bodies to satisfy the constraint. In other words, it's not really about whether you're an interface; it's about whether you have implementations for the static members that the generic type or method may call.