Specify private override errors #2283

eernstg · 2022-06-07T17:15:18Z

Cf. #2263 (comment), this PR eliminates the notion of a 'combined interface' from the language specification and clarifies the specification of how to check override errors. The main point in doing that is that it specifies how incorrect overrides are detected and reported in the case where a class or a similar declaration in a library L gives rise to an error involving private members that aren't accessible to L.

The discussion about this change gave rise to the following summary of the rules.

I've added some remarks inline to indicate that we do in fact have these properties.

More concretely, this means that we end up with the following as the
proposed semantics for the errors and warnings around a given method
m with respect to a class declaration C in library L:

Case: m is declared in C (C is abstract, or concrete, m must be accessible in L by definition)

We don’t require that m have a combined signature in the super-interfaces

We do require that m is a proper override of all signatures for m from all direct super-interfaces

We already specify this requirement for methods, abstract as well as concrete in line 2724.

This PR moves that rule from the section 'Instance Methods' to the section 'Classes', because it is relevant to getters and setters as well (the rule was worded correctly, but it was basically misplaced).

The declared signature of m from C becomes the signature of m in the interface of C

This is already specified in line 4917.

Case: m is not declared in C (m may be accessible in L or not)

We require that a combined member signature for m WRT to the direct super-interfaces of C exist, including private members (i.e. even if m is not accessible in L, we still require that a combined member signature exist for m).

This was not stated unambiguously. This PR changes \ref{interfaceInheritanceAndOverriding} such that it is explicitly defined to be a 'member signature conflict' if an interface brings together two member signatures such that no combined member signature can be computed, and the section about classes says that it is a compile-time error if the interface of the class has any of these member signature conflicts.

This covers mixins as well, because of the phrase 'It is a compile-time error for the mixin declaration if the $M_S$ class declaration would cause a compile-time error' in the section about mixin declarations.

The combined member signature of m becomes the signature of m in the interface of C.

This is defined as the combined member signature of a name with respect to a library, and it is defined as mentioned here in \ref{interfaceInheritanceAndOverriding}.

If C is abstract, we are done: we do not require that C implement its interface

If C is concrete and m is public, we separately require that the concrete implementation of m implement its signature in the interface as defined above.

This is already covered by the section 'Fully Implementing an Interface'.

If C is concrete and m is private to a different library, we introduce a noSuchMethod thrower (forced by privacy) with the combined member signature for m as defined above.

This is already covered here.

These restrictions enforce the following properties:

Every class (abstract or concrete) has a single well-defined signature for every member (accessible or not) in its interface.
Every concrete class has a single well-defined concrete implementation of every member (accessible or not) in its interface, and that implementation correctly implements the signature from the previous bullet.

github-actions · 2022-06-07T17:18:40Z

Visit the preview URL for this PR (updated for commit 2d1bbeb):

https://dart-specification--pr2283-specify-private-over-30v5vvvy.web.app

_{(expires Mon, 18 Jul 2022 17:59:29 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 6941ecd630c4f067ff3d02708a45ae0f0a42b88a}