Mixin can be applied to itself

[sgrekhov]

The following code produces no issues in analyzer and VM

class S {
}

class C = S with S;

main() {
  new C();
}

According to the #25765 (comment) there must be an error.

Dart VM version: 2.9.0-14.0.dev (dev) (Tue Jun 9 09:04:53 2020 +0200) on "windows_x64"

[srawlins]

We now report an error, but the message isn't quite right:

error • 'class S' can't be used in both 'extends' and 'with' clauses. • a.dart:4:18 • mixins_super_class

[lrhn]

I actually don't want this to be an error. I've thought about it, and the only reason it's supposed to be an error is that it desugars to something which implements S and has S as superclass, but the user never wrote implements S, and they shouldn't get hit for something they didn't write.

(And finding another issue, #33596 (comment), confirms that that's not just me, it's what we want).

So, the code must work without an error.

[eernstg]

Of course, S must be a mixin class today.

However, as @lrhn mentioned, it is still an error because a declaration like class C = S with S; and in particular the mixin application S with S itself gives rise to a class that has extends S as well as implements S, which is an error.

OK, the author of the class C did not actually write implements S, but it seems likely that S with ...... S is a mistake, and it is actually more harmful than class A extends B implements B {} (which is actually harmless, except that it is confusing). With duplicated mixins, any instance variables declared by S will be allocated twice, but we may also get duplication of side effects:

int numberOfSes = 0;

mixin class S {
  // ignore:unused_field
  final _dummy = ++numberOfSes;
}

class C = S with S; // Just assume that it is allowed.

main() {
  new C();
  print(numberOfSes); // '2' --- is that correct?
}

The same semantics can be achieved using class C = Object with S, S;, if that's really what we want, but it's probably a good idea to lint that. Duplication of mixins in the same object is a very, very, very special feature and we might actually never encounter a situation where it isn't a mistake. ;-)

[lrhn]

However, as @lrhn mentioned,

That's not what I said, and actually quite the opposite.
I said it should not be an error because the code does not contain an implements S clause.

There is no rule against class C extends S with S {}. The only argument against it is the rule that you can't have the same type
as superclass and have it as an implements clause as well, and because a class which extends S also has S as superinterface, it's taken to mean that it implements S, and that that implicit implements non-clause conflicts with the superclass.

It might be likely that class C = S with S; is a mistake, but that's why we have warnings.

This error is for the case where you write extends S implements S (and we have a similar error for implements S, S, having the same type twice in an implements clause).
That was also the conclusion reached here. I'll stick to that one.
(Also, the front end doesn't have any warnings. Yey!)

I actually think we should remove all those unnecessary errors, and make it up to the analyzer to warn about unnecessary, but unambiguous and well-defined, restatements of the same thing, like implementing the same interface twice. But that's another issue. For now I'll be happy if they only apply to code the author actually write.

[eernstg]

That's not what I said, and actually quite the opposite.

You said that it is an error (with an implied "technically"), but you didn't want it to be an error. I was repeating the 'is' part. ;-)

I don't have a strong opinion here, I just think it has very little value to change the analyzer such that no error is reported.

I actually think we should remove all those unnecessary error.

We could do that, too. The main point is that I don't think we're going to help anybody by simply letting it happen silently.