Skip to content

Adding support for default interface function members #681

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 14 commits into
base: draft-v8
Choose a base branch
from

Conversation

RexJaeschke
Copy link
Contributor

@RexJaeschke RexJaeschke commented Dec 5, 2022

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.

@RexJaeschke RexJaeschke added this to the C# 8.0 milestone Dec 5, 2022
@RexJaeschke RexJaeschke self-assigned this Dec 5, 2022
@RexJaeschke RexJaeschke marked this pull request as draft December 5, 2022 13:54
@RexJaeschke
Copy link
Contributor Author

RexJaeschke commented Dec 6, 2022

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 BillWagner force-pushed the default-interface-function-members branch from 84a1703 to caba5c7 Compare February 6, 2023 13:52
@RexJaeschke RexJaeschke added the type: feature This issue describes a new feature label Jul 22, 2023
@BillWagner BillWagner force-pushed the default-interface-function-members branch from caba5c7 to dc8d7a0 Compare September 25, 2023 20:54
@BillWagner
Copy link
Member

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

@KalleOlaviNiemitalo
Copy link
Contributor

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).

Enclosing a paragraph in brackets breaks the word converter. It looks for a link.
@RexJaeschke RexJaeschke added the Review: pending Proposal is available for review label Oct 13, 2023
@RexJaeschke RexJaeschke removed their assignment Oct 22, 2023
@RexJaeschke RexJaeschke marked this pull request as ready for review January 11, 2024 14:00
@gafter gafter self-assigned this Jan 16, 2024
@RexJaeschke
Copy link
Contributor Author

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.


When an interface `IB` extends an interface `IA`, it is a compile-time error for `IA` to depend on `IB`. An interface **directly depends on** its direct base interfaces (if any) and **directly depends on** the type within which it is immediately nested (if any).

Given these definitions, the complete set of types upon which a type depends is the transitive closure of the *directly depends on* relationship.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Given these definitions, the complete set of types upon which a type depends is the transitive closure of the *directly depends on* relationship.
Given these definitions, the complete set of types upon which a type depends is the reflexive and transitive closure of the *directly depends on* relationship.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The suggested change is required to disallow class A : A {}

>
> *end example*

Every interface and class shall have a most specific override for every virtual member 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is "an override"?

@gafter
Copy link
Member

gafter commented Dec 15, 2024

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
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Review: pending Proposal is available for review type: feature This issue describes a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants