Unable to access default interface methods

[Unknown6656]

I am unsure whether to post this here or in https://github.com/dotnet/roslyn.

When using the current compiler version (either on http://sharplab.io/ or the one in VS2019-v.16.1.1 with dotnet v.3.0.100-preview5-011568) I am unable to get the following code to compile:

01: interface I
02: {
03:     int a() => 1;
04: }
05:     
06: struct S : I
07: {
08:     int b() => a() + 5; // CS0103: The name 'a' does not exist in the current context
09: }

The error disappears when changing line №06 to interface S : I.
I am also able to access the member int I.a() via an explicit cast, e.g. ((I)this).a(), however, the final goal of this feature would be to access the interface methods inside S as if they were implemented explicitly.

Is this a compiler-bug or am I missing something crucial here (e.g. incomplete language specification etc.)?

[YairHalberstadt]

I would post on Roslyn. They'll move it here if it isn't a bug.

[yaakov-h]

IIRC from the LDM notes, that’s by design.

[Unknown6656]

@YairHalberstadt I did not post it in Roslyn, as I assumed that such a critical issue would not pass any unit test -- meaning that it has something to do with the language design.

@yaakov-h cr*p! ...... do you know why?
I am working on a large library designed for mathematics and this feature would reduce a lot of code if it "would work properly" (meaning that default implementations are transferred to the structure implementing the interface in question).

[YairHalberstadt]

It could be to reduce implicit boxing...

Although I imagine the JIT ought to be able to devirtualise this easily.

[HaloFour]

This is by design. Implementing types don't "inherit" the default members. They can only be called through the interface (or generic types constrained to the interface).

[Unknown6656]

Oh well ....... I was really hoping that the default members would be "inherited".

Looks like I have to revert back to T4-Templates to generate type-safe by-value types with a common logic. Maybe someday, the LDT decides to change that behaviour .....

---

Thank you all for your quick replies

[Joe4evr]

Yair is correct, it's entirely to prevent implicit boxing. See also the relevant design notes.