42 lines
2.2 KiB
Markdown
42 lines
2.2 KiB
Markdown
# 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:
|
|
|
|
``` c#
|
|
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:
|
|
|
|
``` c#
|
|
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.
|