Added: LDM Notes for September 13th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-09-13.md

Agenda

1. Feedback on static abstracts in interfaces

[HaloFour]

I'm a little surprised that a form of the concrete constraint discussion didn't come up. To me, not being able to use the interface itself as the generic type argument is one of the weirder aspects of static abstracts, especially since it would seem to result in a TypeLoadException at runtime vs. a compiler error.

[tannergooding]

This is already blocked at the language level because ISomeInterface<T> isn't convertible to ISomeInterface<ISomeInterface<T>>.

• where T : IUnaryPlus<T> means T must implement IUnaryPlus<T>. If T is itself IUnaryPlus<T>, then it must therefore implement IUnaryPlus<IUnaryPlus<T>>. Recursion is fun 😄

You can of course do dangerous things via reflection or unsafe code. But that's always possible and there are many language concepts that don't have representation there.

[HaloFour]

I wasn't referring to that in the case of self type, but I do see that it seems that the language is already enforcing that the interface cannot be used as a generic type argument if it has static abstract members, so perhaps this issue was already discussed/addressed:

error CS9101: The interface 'IBar' cannot be used as type parameter 'T' in the generic type or method 'C.M<T>()'. The constraint interface 'IFoo' or its base interface has static abstract members.

[acaly]

A reproduction of the runtime exception (it's actually System.Security.VerificationException): sharplab.

[acaly]

I think a System.Security.VerificationException is an indication that the language and runtime do not agree on what is a verified program. Since the example program I provided is really invalid, I think there should be something to do for the compiler to generate an error. The runtime can't do much here.

I have mentioned this example for multiple times in at least 3 different issues/discussions, expressing the same idea "not being able to use the interface itself as the generic type argument is one of the weirder aspects of static abstract". However, I haven't got any feedback on how or whether this VerificationException problem would potentially be addressed in the next version of C# or runtime.

[HaloFour]

That's what I think these discussions are for. It sounds like the compiler is attempting to catch and prevent the simple case, but more complicated cases can get through.

This feature is only going out as preview in C# 10 specifically to give people an opportunity to take it for a test drive. How the feature evolves before (potentially) being released as a part of .NET 7/C# 11 will depend on that feedback.

[svick]

We can solve issues like this by implementing a self type, which will also just be a generally-useful feature for the language. We're positive about the feature, but it is going to need a decent amount of design work. In particular, there are interfaces such as IEquatable<T> that have been in C# since C# 2.0, and we need to think about if we want to be able to apply such a constraint to those interfaces, how that would work, and what level of breaking change it would be.

I was curious if there were types that would be broken by this in the BCL and didn't find any there, but I did find some in ClrMD, like CLrArray:

public struct ClrArray : IEquatable<ClrArray>, IEquatable<ClrObject>

[alrz]

I wouldn't consider the existing IEquatable<T> as a "type class" for equality. There's IEqualityOperators.

[acaly]

I wouldn't consider the existing IEquatable<T> as a "type class" for equality. There's IEqualityOperators.

I think no matter whether and how we will have self type constraint, IEquatable and IEqualityOperators are 2 different type classes. operator== isn't identical to (and thus a replacement of) Equals method today, for example, in the case of NaN equality, so both would be necessary.