csharplang/meetings/2017/LDM-2017-04-11.md

C# Language Design Notes for Apr 11, 2017

Agenda

1. Runtime behavior of ambiguous default implementation

Runtime behavior of ambiguous default implementation

The feature is intended to work when a new default-implemented member is added to an interface I, even when an implementing class C is not recompiled. So the runtime needs to know about default implementations and be able to find them.

In the case of overrides, there may be diamond-hierarchy cases where the compiler knows of only one override, but one is added later to another interface. The implementations are now ambiguous, and a recompilation would cause an ambiguity, but it would seem desirable that the runtime should choose "the one the compiler knew about"; that, somehow, that knowledge would be baked in to the compiled class C.

Starting out with these type declarations in separate assemblies:

interface I1 { void M() { Impl1 } }
interface I2 : I1 { override void M() { Impl2 } }
interface I3 : I1 { }
class C : I2, I3 { }

Everyone's happy, and C's implementation of M would unambiguously come from I2.

Now I3 is modified and recompiled:

interface I3 : I1 { override void M() { Impl3 } }

What should happen at runtime? When C was compiled, it "thought" everything was alright. At runtime it isn't. Can the compilation of C bake in a preference based on its understanding of the world at the time of compilation? Should it?

It is not obvious how this would work. What if the default implementation C depends on is moved, deleted or overridden? Should it just be a "vague" preference in case of ambiguity, to get the runtime on the right track?

This seems complicated, fragile and fraught with peril, but ending up with an ambiguity at runtime is also bad.

Regardless, there will always be runtime ambiguities; "baking in" preferences would only address a subset. Two open questions:

1. Should we try to help resolve ambiguities by baking in compile time preferences? Unresolved.
2. Should we fail or pick an "arbitrary" implementation in case of inevitable ambiguities at runtime? Unresolved. Bad to error. Bad to run "arbitrary" code.

We should look more deeply into what Java does here. There must be accumulated insight already on this topic.