Should augmentations allow appending to the implements clause for extension types?

[jakemac53]

We do not allow altering the representation type, and require the clause for that to be present, but we don't mention the implements clause.

cc @dart-lang/language-team

[lrhn]

I assume this means extension mixin types ... nope, I can't figure it out. Which declaration is this?

There is no declaration that has both an on clause and a with clause. The only declarations which have a with clause is class and enum declarations, which cannot have an on clause. The declarations with on clauses are extension and mixin, which cannot have a with clause.

The full grammars of the declarations are something like:

extension type const Name<X1, X2>.id(RepType id) implements I1, I2 { ... }
extension Name<X1, X2> on T { ... }
mixin Name<X1, X2> on T1, T2 implements I1, I2 { ... }
abstract base class Name<X1, X2> extends T with T1, T2 implements I1, I2 {}
abstract base class Name<X1, X2> = T with T1, T2 implements I1, I2 {}
abstract base mixin class Name<X1, X2> implements I1, I2 {}
enum Name<X1, X2> with T1, T2 implements I1, I2 {}

[jakemac53]

I just wrote it wrong, I meant the implements clause :)

[eernstg]

I think it should not be a problem to allow it. A longer implements clause would add to the available subtype relationships, but I don't think it will undo any existing assumptions for that declaration. Of course, there could be issues that correspond to the ones we can have with classes (like the non-existence of a combined member signature for a member, or a clash that can't be resolved like int get foo in one superinterface and int foo() in another).

[jakemac53]

Yeah, I think it is mostly a philosophical question. We choose to for instance not allow filling in the on clause for extensions, or the representation type clause for extension types. Just because it is pretty weird to omit those.

But, we allow filling in implements on classes, so it seems a bit odd to not allow it on extension types.

[eernstg]

Right, but adding an implements type to an extension type seems "no worse" than adding an implements type to a class, I'd think.

(haha, same edit ;-)

[jakemac53]

Yeah I am inclined to allow it 👍

[lrhn]

Agree. I'd prefer that implements behaves the same everywhere. It's stricty worse to be able to add interfaces to classes, mixins and enums, but not extension types.

[jakemac53]

Ok, I will go ahead and add it into the builder APIs for macros (which is where I realized this omission).