Adding support for default interface function members #681

RexJaeschke · 2022-12-05T13:54:36Z

Re the MS proposal: The main challenge when reading it was the (misleading) occurrence of the modifier override in numerous examples and narrative. As best as I can tell, this modifier is not actually permitted on any interface member. Instead, overriding is achieved via explicit implementation.

There is one open question, which has to do with the topic "Base Interface Invocations," for which the decision "Decided on base(N.I1<T>).M(s)" was made. However, as far as I can tell, support for this was not added to the V8 compiler. Can someone please confirm (or refute) that.

BTW, I think the proposal is misnamed: it really applies to all interface function members (properties, indexers, and events as well), not just methods. (it also allows nested types.)

Note: No spec changes are needed to support entry point Main in an interface. Any non-generic type containing a Main method with void/int return and no/one string[] parameter list is already permitted, which not only allows Main in a struct or class, but now also in an interface.

As of V7, the descriptions of the various member kinds has been located in classes.md, with augmenting and/or overriding text in structs.md, with pointers from structs.md back into classes.md, and that continues. However, now that many members kinds can have implementations in interfaces as well, I've added an intro para to the start of most member sections in classes.md, which contains forward pointers to that member kind's occurrence in structs.md and interfaces.md, as appropriate.

Fixes #982 (which reinstates abstract override.)

RexJaeschke · 2022-12-06T17:15:06Z

Depending how PR #680 is resolved, some tweaks might be needed with this PR.

As at 2025-05-03, that PR is still pending, and is tied to the review of this PR.

BillWagner · 2023-09-25T20:54:24Z

rebased on the latest draft-v8 on 09-23-2023

KalleOlaviNiemitalo · 2023-09-25T21:23:24Z

Should the references to "C# implementations targeting the CLI" be changed somehow because the ECMA standard CLI does not support default interface members? Possible answers include:

Remove them; C# 8 implementations cannot target "the CLI".
Change them to say "targeting a CLI with extensions" or the like.
Keep them; a C# implementation can still target the standard CLI, although the mapping may become complex or inefficient or have restrictions (like not supporting dynamic loading of assemblies that were not provided at build time).

RexJaeschke · 2024-11-12T21:52:19Z

Re @KalleOlaviNiemitalo's concern about the Ecma CLI standard not supporting default interface function members, we previously made a related change to the draft-v8 Introduction, which in V7, said:

... Although Microsoft’s implementation of C# relies on CLI for library and run-time support, other implementations of C# need not, provided they support an alternate way of getting at the minimum CLI features required by this C# standard (see Annex C).

It now says:

... Although Microsoft’s implementation of C# relies on CLI for library and run-time support, other implementations of C# need not, provided they support the features and API required by this C# Standard (see Annex C).

I think that allows us to say nothing more for this feature with regard to the CLI.

standard/classes.md

standard/interfaces.md

gafter · 2024-12-15T01:14:52Z

I don't recall why this is assigned to me. Is it for general review, or to answer the question about base(T).M()? If the latter, see the following:

In short, the base(T).M() syntax has not been added to the language yet.

BillWagner · 2024-12-15T16:13:38Z

@gafter

I don't recall why this is assigned to me. Is it for general review, or to answer the question about base(T).M()?

Going from memory, but I believe as a general reviewer.

RexJaeschke · 2025-05-28T15:16:23Z

closed and reopened to get all tests to run

jskeet · 2025-06-11T13:09:31Z

@RexJaeschke and @BillWagner could you look at resolving the conflict?

I'm not sure whether we can realistically expect most members to have reviewed this before the meeting later today though. (I'll see whether I can find time, but I'm prioritizing #606.)

BillWagner · 2025-06-11T14:07:31Z

@RexJaeschke and @BillWagner could you look at resolving the conflict?

I'm not sure whether we can realistically expect most members to have reviewed this before the meeting later today though. (I'll see whether I can find time, but I'm prioritizing #606.)

@jskeet I did a full rebase.

My main goal in prioritizing this for today's meeting is to get it assigned to someone for next meeting. I agree that there isn't time to get it reviewed thoroughly.

jskeet · 2025-06-25T08:29:15Z

@BillWagner Looking again, did we get as far as assigning it during the last meeting? We spent quite a bit of time talking about prose vs grammar for constraints, but we didn't record the next step...

BillWagner

Updated in the latest commit.

standard/interfaces.md

Clarify the rules on overriding interface members with implementations, and on accessing members with an implementation in an interface.

standard/interfaces.md

Co-authored-by: Joseph Musser <[email protected]>

BillWagner · 2025-09-15T17:25:20Z

Thanks to @Nigel-Ecma for the updated grammar validation.

This is ready for a 2nd review. I'll watch for comments between now and our meeting, and address all those I can before the meeting.

I've updated the semantics on visibility and accessibility of members defined (not just declared) in an interface, along with the definition of "most specific override". Reviews should check the semantics both for correctness and clarify.

Open question for meeting discussion: See #681. Looking into our future, do we want to make the class, struct and interface grammar(s) more unified? If so, when? Where do we want to rely on semantic rules in text to disallow constructs that are consistent with the grammar?

standard/interfaces.md

jskeet

A few comments - these are all I could actively find as new points of concern, but I have weak confidence in my own reviewing capability of this PR.

standard/interfaces.md

jskeet · 2025-09-24T19:20:26Z

In the meeting, we weren't sure of the behavior of this:

class Program
{
    static void Main()
    {
        C c = new C();
        I i = c;

        c.M();
        i.M();
    }
}

interface I
{
    void M() => Console.WriteLine("I.M()");
}

class C : I
{
    public void M() => Console.WriteLine("C.M()");
}

It compiles, and prints C.M() twice. So it's fine for a class to implement an interface and "override" the default implementation, and it still uses the "override" however it's accessed.

standard/interfaces.md

BillWagner

adding comments

standard/interfaces.md

Addressed

Edit files other than interfaces post meeting

Updates terminology from 'override' to 'implementation' for interface members, clarifies rules for hiding and explicitly implementing inherited members, and improves examples and notes for interface member access and inheritance. Adds details about the use of the 'new' modifier and compiler warnings, and refines explanations of most specific implementation in diamond inheritance scenarios.

BillWagner

I addressed all comments from the 9/25 meeting. I'll resolve relevant conversations.

standard/interfaces.md

Nigel-Ecma

(@BillWagner – you were making updates in parallel so some of my comments may have been preemptively dealt with.)

I will admit I ran out of steam going through all the semantic restrictions on the grammar in interfaces.md.

I haven’t checked the grammar does what is expected, or written any tests to add to the grammar checking phase – I will leave both till after this is merged.

I think this is close :-)

standard/basic-concepts.md

standard/classes.md

standard/basic-concepts.md

standard/interfaces.md

Nigel-Ecma · 2025-09-26T01:48:45Z

standard/interfaces.md

+- An explicitly implemented function member shall not have the modifier `sealed`.

-An *interface_declaration* creates a new declaration space ([§7.3](basic-concepts.md#73-declarations)), and the type parameters and *interface_member_declaration*s immediately contained by the *interface_declaration* introduce new members into this declaration space. The following rules apply to *interface_member_declaration*s:
+Some declarations, such as *constant_declaration* (§15.4) have no restrictions in interfaces.


This feels a little superfluous as everything that is different is listed, but I also guess its harmless…

I don't have strong feelings. I added this so that readers that compare class members with interface members and might think it was an omission.

Nigel-Ecma · 2025-09-26T02:03:26Z

standard/interfaces.md

+Interface indexers are declared using *indexer_declaration*s ([§15.9](classes.md#159-indexers)), with the following additional rules:
+
+- *indexer_modifier* shall not include `override`.
+- An *indexer_declaration* that has an *expression body* or contains an accessor with a body is `virtual`; the `virtual` modifier is not required, but is allowed.


Maybe:

Suggested change

- An *indexer_declaration* that has an *expression body* or contains an accessor with a body is `virtual`; the `virtual` modifier is not required, but is allowed.

- An *indexer_declaration* that has an expression body or contains an accessor with a block body is `virtual`; the `virtual` modifier is not required, but is allowed.

in other clauses here expression body is not emphasised and block body is used.

This is the one comment where we crossed. They are all consistent now. You can resolve this is you're satisfied with the change.

Address review comments from Nigel on 9/25-26

BillWagner

Comments from edits base on Nigel's latest review

standard/basic-concepts.md

standard/classes.md

standard/interfaces.md

BillWagner · 2025-09-26T17:14:43Z

standard/interfaces.md

+- An explicitly implemented function member shall not have the modifier `sealed`.

-An *interface_declaration* creates a new declaration space ([§7.3](basic-concepts.md#73-declarations)), and the type parameters and *interface_member_declaration*s immediately contained by the *interface_declaration* introduce new members into this declaration space. The following rules apply to *interface_member_declaration*s:
+Some declarations, such as *constant_declaration* (§15.4) have no restrictions in interfaces.


I don't have strong feelings. I added this so that readers that compare class members with interface members and might think it was an omission.

BillWagner · 2025-09-26T17:19:17Z

standard/interfaces.md

+Interface indexers are declared using *indexer_declaration*s ([§15.9](classes.md#159-indexers)), with the following additional rules:
+
+- *indexer_modifier* shall not include `override`.
+- An *indexer_declaration* that has an *expression body* or contains an accessor with a body is `virtual`; the `virtual` modifier is not required, but is allowed.


This is the one comment where we crossed. They are all consistent now. You can resolve this is you're satisfied with the change.

jnm2 · 2025-09-27T17:51:45Z

standard/interfaces.md

 The set of members of an interface declared in multiple parts ([§15.2.7](classes.md#1527-partial-type-declarations)) is the union of the members declared in each part. The bodies of all parts of the interface declaration share the same declaration space ([§7.3](basic-concepts.md#73-declarations)), and the scope of each member ([§7.7](basic-concepts.md#77-scopes)) extends to the bodies of all the parts.

-> *Example*: Consider an interface `IA` with an implementation for a member `M`. As `M` is not abstract, outside that interface or any interface derived from it, that name is not visible. It must be accessed through a reference whose compile-time type is an interface that is implicitly convertible to `IA`.
+> *Example*: Consider an interface `IA` with an implementation for a member `M` and a property `P`. An implementing type `C` doesn't provide an implementation for either `M` or `P`. They must be accessed through a reference whose compile-time type is an interface that is implicitly convertible to `IA` of `IB`. These members aren't found through member lookup on a variable of type `C`.


Suggested change

> *Example*: Consider an interface `IA` with an implementation for a member `M` and a property `P`. An implementing type `C` doesn't provide an implementation for either `M` or `P`. They must be accessed through a reference whose compile-time type is an interface that is implicitly convertible to `IA` of `IB`. These members aren't found through member lookup on a variable of type `C`.

> *Example*: Consider an interface `IA` with an implementation for a member `M` and a property `P`. An implementing type `C` doesn't provide an implementation for either `M` or `P`. They must be accessed through a reference whose compile-time type is an interface that is implicitly convertible to `IA` or `IB`. These members aren't found through member lookup on a variable of type `C`.

jnm2 · 2025-09-27T17:54:40Z

standard/interfaces.md


 - *method_modifier* shall not include `override`.
- An interface method declaration that has a block body or expression body as a *method_body* has an implementation ([§19.1](interfaces.md#191-general)), so it is *not* abstract.
+- A method whose body is a semi-colon (`;`) is `abstract`; the `abstract` modifier is not required, but is allowed.


Interesting. I intuitively refer to the presence of the semicolon as "having no body." Does the spec have an opinion yet on whether methods with semicolons have "semicolon bodies" or "no bodies"?

One nice thing about referring to this as "having no body" is that we can then just say "has a body" instead of saying "has a block body or expression body."

jnm2 · 2025-09-27T18:02:43Z

standard/interfaces.md

 - *indexer_modifier* shall not include `override`.
- An *indexer_declaration* that has an *expression body* or contains an accessor with a body is an implementation ([§19.1](interfaces.md#191-general)), so it is *not* abstract.
+- An *indexer_declaration* that has an *expression body* or contains an accessor with a body is `virtual`; the `virtual` modifier is not required, but is allowed.
+- An *indexer_declaration* whose accessors are semi-colons (`;`) is `abstract`; the `abstract` modifier is not required, but is allowed.


I would say that the accessor is get;, not that the accessor is ;. The accessor has a semi-colon. Per the previous comment, could we adopt the lingo here of "whose accessors have no bodies"?

jnm2 · 2025-09-27T18:06:07Z

standard/interfaces.md

+### §most-specific-implementation most specific implementation

-Every interface and class shall have a most specific override for every virtual member declared in all interfaces implemented by that type among the overrides appearing in the type or its direct and indirect interfaces. The ***most specific override*** is a unique override that is more specific than every other override. If there is no override, the member itself is considered the most specific override.
+Every class and struct shall have a most specific implementation for every virtual member declared in all interfaces implemented by that type among the overrides appearing in the type or its direct and indirect interfaces. The ***most specific implementation*** is a unique override that is more specific than every other override. If there is no override, the member itself is considered the most specific implementation.


I'm finding it confusing to bring in the topic of overrides at all. Do we need to?

Suggested change

Every class and struct shall have a most specific implementation for every virtual member declared in all interfaces implemented by that type among the overrides appearing in the type or its direct and indirect interfaces. The ***most specific implementation*** is a unique override that is more specific than every other override. If there is no override, the member itself is considered the most specific implementation.

Every class and struct shall have a most specific implementation for every virtual member declared in all interfaces implemented by that type among the implementations appearing in the type or its direct and indirect interfaces. The ***most specific implementation*** is a unique implementation that is more specific than every other implementation.

jnm2 · 2025-09-27T18:08:40Z

standard/interfaces.md

- The expression `base.M()` is valid only if `B` provides a definition for `M`. The expression `base.M()` is valid only if the most specific implementation (§most-specific-implementation) of `M` is in a class type. To access the most specific implementation if it was defined in an interface, use the cast expression `(this as I).M()` to refer to the most specific implementation (§most-specific-implementation) of `M` in `I` or an interface derived from `I`.
- If `B` contains a method `M` without the `virtual` or `override` modifier, that method hides `I.M()` rather than overriding it.
- If `B` contains a method `M` with a different parameter list, that method `M` is a distinct overload of `M`.
+In a class `D`, with direct or indirect base class `B`, where `B` directly or indirectly implements interface `I` and `I` defines a method `M()`, the expression `base.M()` is valid only if the most specific implementation (§most-specific-implementation) of `M()` is in a class type.


It's much clearer to say that the validity of base.M() depends entirely on whether some base class defines its own member M(). Whether or not its own member M() is an implementation of some I.M() does not affect the validity of base.M() one way or another.

This is again another case of: interface member names do not appear on classes and structs. An interface member is never available for lookup on a class- or struct-typed expression. A member is available for lookup on a class- or struct-typed expression if, and only if, the class or struct manually declares such a member of its own, accessibly. It may or may not be implementing an interface member in doing so.

Also, here's an example where the expression base.M() is valid, but the most specific implementation of I.M() is not in a class type:

interface I { void M() => Console.WriteLine("impl"); } class B : I { public Action M => () => Console.WriteLine("Unrelated impl via a property"); } class D : B { void Example() => base.M(); // This is not I.M(); }

RexJaeschke added this to the C# 8.0 milestone Dec 5, 2022

RexJaeschke self-assigned this Dec 5, 2022

RexJaeschke marked this pull request as draft December 5, 2022 13:54

BillWagner force-pushed the default-interface-function-members branch from 84a1703 to caba5c7 Compare February 6, 2023 13:52

RexJaeschke added the type: feature This issue describes a new feature label Jul 22, 2023

BillWagner force-pushed the default-interface-function-members branch from caba5c7 to dc8d7a0 Compare September 25, 2023 20:54

BillWagner mentioned this pull request Sep 29, 2023

Consider reordering and reorganizing sections #959

Open

RexJaeschke mentioned this pull request Oct 2, 2023

New Language Features that Rely on Features NOT in the Current CLI Spec #962

Closed

RexJaeschke added the Review: pending Proposal is available for review label Oct 13, 2023

RexJaeschke removed their assignment Oct 22, 2023

RexJaeschke mentioned this pull request Nov 1, 2023

Add support for init accessors #978

Draft

RexJaeschke marked this pull request as ready for review January 11, 2024 14:00

gafter self-assigned this Jan 16, 2024

gafter reviewed Dec 11, 2024

View reviewed changes

standard/classes.md Outdated Show resolved Hide resolved

gafter reviewed Dec 11, 2024

View reviewed changes

standard/interfaces.md Outdated Show resolved Hide resolved

RexJaeschke unassigned gafter May 14, 2025

RexJaeschke closed this May 28, 2025

RexJaeschke reopened this May 28, 2025

RexJaeschke added the meeting: priority Review before meeting. Merge, merge with issues, or reject at the next TC49-TC2 meeting label Jun 10, 2025

BillWagner force-pushed the default-interface-function-members branch from 22549fb to efb69e5 Compare June 11, 2025 13:57

BillWagner reviewed Sep 10, 2025

View reviewed changes

standard/interfaces.md Outdated Show resolved Hide resolved

Clarify more on access to interface members

28e3391

Clarify the rules on overriding interface members with implementations, and on accessing members with an implementation in an interface.

jnm2 previously requested changes Sep 11, 2025

View reviewed changes

standard/interfaces.md Outdated Show resolved Hide resolved

standard/interfaces.md Outdated Show resolved Hide resolved

BillWagner and others added 6 commits September 11, 2025 13:59

Apply suggestions from code review

0b58bdd

Co-authored-by: Joseph Musser <[email protected]>

Merge branch 'draft-v8' into default-interface-function-members

96e844d

update anchor

f424d4f

update xrefs

0c039de

more anchor cleanup

2eb6fe0

Update grammar tests for DIM

53f2bab

gafter reviewed Sep 19, 2025

View reviewed changes

standard/interfaces.md Outdated Show resolved Hide resolved

jskeet reviewed Sep 23, 2025

View reviewed changes

jskeet reviewed Sep 24, 2025

View reviewed changes

standard/interfaces.md Outdated Show resolved Hide resolved

BillWagner reviewed Sep 24, 2025

View reviewed changes

standard/interfaces.md Outdated Show resolved Hide resolved

standard/interfaces.md Outdated Show resolved Hide resolved

jnm2 reviewed Sep 24, 2025

View reviewed changes

standard/interfaces.md Outdated Show resolved Hide resolved

BillWagner added 2 commits September 25, 2025 13:56

mostly grammar edits

3d198d4

Edit files other than interfaces post meeting

BillWagner reviewed Sep 25, 2025

View reviewed changes

lint

9f75cf4

Nigel-Ecma requested changes Sep 26, 2025

View reviewed changes

RexJaeschke mentioned this pull request Sep 26, 2025

Saying as much as possible in grammar rules vs. saying less there and augmenting with semantic rules in narrative #1423

Open

Address review comments

7b843a2

Address review comments from Nigel on 9/25-26

BillWagner reviewed Sep 26, 2025

View reviewed changes

jnm2 reviewed Sep 27, 2025

View reviewed changes

	- An indexer_declaration that has an expression body or contains an accessor with a body is `virtual`; the `virtual` modifier is not required, but is allowed.
	- An indexer_declaration that has an expression body or contains an accessor with a block body is `virtual`; the `virtual` modifier is not required, but is allowed.

	> Example: Consider an interface `IA` with an implementation for a member `M` and a property `P`. An implementing type `C` doesn't provide an implementation for either `M` or `P`. They must be accessed through a reference whose compile-time type is an interface that is implicitly convertible to `IA` of `IB`. These members aren't found through member lookup on a variable of type `C`.
	> Example: Consider an interface `IA` with an implementation for a member `M` and a property `P`. An implementing type `C` doesn't provide an implementation for either `M` or `P`. They must be accessed through a reference whose compile-time type is an interface that is implicitly convertible to `IA` or `IB`. These members aren't found through member lookup on a variable of type `C`.

Adding support for default interface function members #681

Are you sure you want to change the base?

Adding support for default interface function members #681

Uh oh!

Conversation

RexJaeschke commented Dec 5, 2022 • edited by BillWagner Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RexJaeschke commented Dec 6, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BillWagner commented Sep 25, 2023

Uh oh!

KalleOlaviNiemitalo commented Sep 25, 2023

Uh oh!

RexJaeschke commented Nov 12, 2024

Uh oh!

Uh oh!

Uh oh!

gafter commented Dec 15, 2024

Uh oh!

BillWagner commented Dec 15, 2024

Uh oh!

RexJaeschke commented May 28, 2025

Uh oh!

jskeet commented Jun 11, 2025

Uh oh!

BillWagner commented Jun 11, 2025

Uh oh!

jskeet commented Jun 25, 2025

Uh oh!

BillWagner left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

BillWagner commented Sep 15, 2025

Uh oh!

Uh oh!

jskeet left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jskeet commented Sep 24, 2025

Uh oh!

Uh oh!

BillWagner left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

BillWagner left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Nigel-Ecma left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RexJaeschke commented Dec 5, 2022 •

edited by BillWagner

Loading

RexJaeschke commented Dec 6, 2022 •

edited

Loading

Nigel-Ecma left a comment •

edited

Loading

jnm2 Sep 27, 2025 •

edited

Loading

jnm2 Sep 27, 2025 •

edited

Loading