Motivation and interpretation of interface restriction in 12.1

[stereotype441]

The modification to section 12.1 ("Mixin Application") says: "Let C be a class declaration that includes M_A in a with clause. It is a static warning if C does not implement, directly or indirectly, all the direct superinterfaces of M."

If I understand correctly, the following code would produce the warning:

abstract class I {}
abstract class M implements I {}
class C extends Object with M {} // Warning: must declare "implements I"

Should I understand "Let C be a class declaration..." to also refer to mixin application declarations? In other words, would the following code also produce the warning?

abstract class I {}
abstract class M implements I {}
class App = Object with M; // Warning: must declare "implements I"?
class C extends App {}

I hope the answer is yes, because these two code examples ought to be equivalent.

Assuming my understanding is correct, what's the motivation for requiring the user to explicitly add the "implements" clause rather than making it implicit? In other words, couldn't we drop this paragraph from the spec and instead modify the existing paragraph in section 12.1 as follows (addition in bold):

If the mixin application or the class M declare support for interfaces, the resulting class implements those interfaces.

It seems like this would be more intuitive, since it would mean that in effect, interfaces are inherited via "with" clauses in the same way that they are already inherited by "extends" and "implements" clauses.

(Incidentally, AFAICT the analyzer already implements exactly what I'm proposing, presumably due to a misunderstanding of the spec on our part. I didn't notice this was the case until reading the DEP! I'll file an analyzer bug once the bug migration process settles down. However, I take this as evidence that if we changed the spec to match the analyzer behavior, there would probably not be any objection.)

[gbracha]

(1) Yes, C is any class declaration,including a mixin application as you suggest.

(2) I think we could do as you suggest. I'll look into it.

[gbracha]

To be clear, we should ensure that all methods required by the direct superinterfaces of M are in fact implemented by C (directly or indirectly via inheritance from its superclass) unless it is abstract. We should do this as you suggest. I will clarify the proposal.

[gbracha]

Turns out existing rules take care of this. Removed the extra warning from the proposal.