Added: LDM notes for Oct. 17, 2018

[agocke]

C# Language Design Notes for Oct 17, 2018

Agenda

1. Open issues with default interface methods
2. Target typed new with default constructors on structs

[HaloFour]

Warning for struct not implementing default method?

To reiterate my question, is this not something that could be solved by the runtime so there is no inadvertent box?

[Logerfo]

Does an override in an interface introduce a new member?
No override keyword in interfaces. This should resolve all listed questions.

I'm not sure if I got this right. Does that mean that the following code will not be valid?

interface I1
{
   void M();
}

interface I2 : I1
{
   override void M() { } 
}

[gafter]

@Logerfo That is correct. The correct syntax to use will be

interface I1
{
   void M();
}

interface I2 : I1
{
   void I1.M() { } 
}

[gafter]

To reiterate my question, is this not something that could be solved by the runtime so there is no inadvertent box?

Not if the this parameter in an interface implementation is of the containing type.

[HaloFour]

@gafter

Not if the this parameter in an interface implementation is of the containing type.

Indeed. The only thing that I could think of that could be done to prevent the box there is to have this be of some kind of generic type constrained to the interface and have the compiler output constrained. prefixed calls. But I have no idea how practical that would be or what weird further impact that could have, such as what happens if you pass this to a generic method where the generic type is inferred.

I just think it's a real shame to have to live with this wart and I could see it unexpectedly biting people. It's be nice if default implementations could be functionally identical to explicit implementations on structs in this regard.

[gafter]

The only thing that I could think of that could be done to prevent the box there is to have this be of some kind of generic type constrained to the interface and have the compiler output constrained. prefixed calls. But I have no idea how practical that would be or what weird further impact that could have, such as what happens if you pass this to a generic method where the generic type is inferred.

We followed this design direction for a little while and found it exceedingly complex. It would probably more than double the complexity of the feature for questionable user value.

[HaloFour]

@gafter

We followed this design direction for a little while and found it exceedingly complex. It would probably more than double the complexity of the feature for questionable user value.

Understood. I appreciate that you guys at least explored such an option even if it wasn't found to be worth the complexity. It's a shame that the CLR will have this wart.