Added: C# Language Design Notes for Apr 19, 2017

[MadsTorgersen]

C# Language Design Notes for Apr 19, 2017

1. Improved best common type
2. Diamonds with classes
3. Structs and default implementations
4. Base invocation

Please discuss.

[pentp]

Since default implementations need runtime support anyway and it would be desirable for default implementations to work as if they were implemented directly on the type, wouldn't it be possible to relax/amend the IL rules for default implementations to always have an implicit .constrained prefix on every callvirt instruction on this-typed values. Basically have the runtime synthesize a struct specific IL stream of the default implementation on-demand. Or would it be too fragile/complex?

[mburbea]

I really don't like the idea that structs being forced to box to use interface methods.
I mostly agree with pentp, structs should always invoke these members as by-ref and constrained to the type. That's pretty much how the il for generic methods works that is constrained to an interface.
I like the idea of the hidden type parameter, who cares if we can't name it.
I especially don't like the fact that the situation can't be be improved in a future runtime without incurring breaking changes.

[casperOne]

Improved best common type will be a huge improvement.

I run into that almost daily.

[miloush]

base(T): We could actually expand it to work on classes too, to allow a more distant base implementation to be called.

+1 on that one

[HaloFour]

We could actually expand it to work on classes too, to allow a more distant base implementation to be called.

That actually kind of scares me a little. Is it a good idea to allow a derived class to intentionally jump its parents' override?

[alrz]

@HaloFour How come it's not scary for interfaces?

[HaloFour]

@alrz

How come it's not scary for interfaces?

I'm not sure that I understand the question. The purpose of the operator is to disambiguate calling a parent default member when it is brought in by more than one interface. That wouldn't bypass the inheritance tree, unless the LDM allows for it to jump the implemented member of a parent class. In that case I'd have the same reservation.

Java doesn't directly allow for a derived class to use Class.super to invoke the default member of an interface unless the derived class also implements that interface directly:

public interface Foo {
    default String getValue() { return "Foo"; }
}

public interface Bar {
    default String getValue() { return "Bar"; }
}

public class Baz implements Foo, Bar {
    @Override public String getValue() { return "Baz"; }
}

public class Fizz extends Baz implements Foo {
    @Override public String getValue() {
        String value1 = Foo.super.getValue(); // legal since Fizz implements Foo directly
        String value2 = Bar.super.getValue(); // compiler error
        String value3 = Baz.super.getValue(); // compiler error
        return "Fizz";
    }
}

[alrz]

I'm not sure that I understand the question.

I was trying to say that base(DirectOrIndirectBaseClass) in classes wouldn't be much different from base(DirectOrIndirectBaseInterface) in interfaces (or classes).

[HaloFour]

@alrz

I disagree. A class hierarchy is much more rigid than interface implementation. Any derived class can reimplement an interface, but a derived class can't "re-inherit" it's grandparent. To allow a derived class to directly invoke its grandparent's method bypassing an override on its parent feels like breaking the contract of the parent.

[miloush]

@HaloFour

It's like with everything, you can use it for good and bad. It's the same situation when the contract is that you must call base's implementation in an override. People can either do it or not, but I don't think language should be deciding on what the contract is.

Besides, it doesn't feel that much like it's breaking contract of the parent to me. The contract of the parent is 'I allow the you to do whatever you want at this place', which includes replicating the grandparent's implementation. If you copy&paste it or call it directly does not matter that much.

[HaloFour]

It's like with everything, you can use it for good and bad.

By enshrining it as a language feature the team immediately endorses its use in such a manner. As such it is my opinion that it must be demonstrated that the feature brings sufficient "good" value over potential abuse.

There hasn't been a single proposal to add this kind of functionality to the language on CodePlex or either Github repo. While I certainly appreciate that the LDM is following the rabbit down different holes this is clearly not a problem that this community has found to be pressing.

It's the same situation when the contract is that you must call base's implementation in an override.

It's one thing to "break" a convention by not calling a parent method. Invoking the grandparent is a violation of encapsulation. The grandchild should have no idea what the grandparent does; the parent mediates that relationship.

If you copy&paste it or call it directly does not matter that much.

Sure it does. The actual grandparent implementation has access to information that the derived class does not, namely every private field declared on the grandparent as well as internal fields on other types if you're crossing an assembly barrier.

[miloush]

Copy&paste was an extreme case of course, replicating grandparent's behavior could involve more, although I will give you the cross-assembly internal fields, that's a good one.

The language should also be consistent. If base(X) works somewhere, it should work elsewhere too, otherwise it is confusing and increases complexity, which sometimes might be justified, but I am not entirely convinced this is the case.

I agree that the demand for it has been low. I myself have only run into this limitation once or twice in my life, and there are always means to workaround it (such as adding extra non-virtual methods as has become practice), it is just about how much extra code you ask the user to write.

Invoking the grandparent is a violation of encapsulation. The grandchild should have no idea what the grandparent does; the parent mediates that relationship.

I am personally not against this pattern, I just don't think it's language's job to decide what relationship should grandchild and grandparent have, or whether violation of encapsulation is a bad thing.

By the way, what happens when the base(T).Bla() turns out to be abstract?

[miloush]

Also, is T in base(T) limited to types that are accessible to you? Well I assume the answer is obviously yes, but that is just a consequence of choosing it over base.base. syntax, which wouldn't have solved the original problem for interfaces...

What happens then if you have C : B1 : B2, where at least B1 is different assembly, you call base(B2) in C and then you recompile B1 so that it no longer derives from B2?

To be fair, they said let's decide it later. :)

[Joe4evr]

By the way, what happens when the base(T).Bla() turns out to be abstract?

Currently, if you implement an abstract member and attempt to call it with base, the compiler gives you an error. I would think this remains unchanged if skipping to grandparents were allowed (of which, I'm with HaloFour and not a big fan of the prospect).

Also, is T in base(T) limited to types that are accessible to you?

Considering that it's illegal in C# to increase visibility compared to the base class, why would you even ask? ¯\_(ツ)_/¯

It's the same situation when the contract is that you must call base's implementation in an override.

Off-topic, but I would love an attribute+analyzer that could enforce calling the base implementation where specified.