Add "mixin class" to the "base-interface-final" proposal. (#2674)

* Add "mixin class" to the "base-interface-final" proposal.

I went ahead and took the more aggressive step of also saying that you
can't mixin a class unless it has the "mixin" modifier. However, that
rule is gated by a language version so that it's not breaking.

Since "mixin class" allows you to preserve the previous behavior of
class+mixin, I think we can get away with doing this change in one step.
Basically, whenever you upgrade your library to the latest version, you
add "mixin" to whatever classes you want to support being used as mixins
and you're done.

If you think that's too aggressive, let me know and I can change this.
If we do that, though, it ends up meaning that the "mixin" modifier
doesn't actually *do* anything (except yell at you if you apply it to a
class with a generative constructor or non-Object superclass).

* Revise.

Author: munificent

working/base-interface-final/feature-specification.md

@@ -31,6 +31,10 @@ proposal, this proposal is non-breaking.
 https://github.com/dart-lang/language/issues/2595
 [leaf proposal]: https://github.com/dart-lang/language/issues/2595
 
+This proposal also allows `mixin` to be used as a modifier on `class` to
+indicate that a type is explicitly intended to be used as both a class and a
+mixin.
+
 ## Motivation
 
 Dart's ethos is to be permissive by default. When you declare a class, it can be
@@ -406,14 +410,59 @@ This proposal takes the last option where types have exactly the restrictions
 they declare but a lint can be turned on for users who want to be reminded if
 they re-add a capability in a subtype.
 
-Finally, to the actual proposal...
+## Mixin classes
+
+In line with Dart's permissive default nature, Dart allows any class declaration
+to also be used as a mixin (in spec parlance, it allows a mixin to be "derived
+from a class declaration"), provided the class meets the restrictions that
+mixins require: Its immediate superclass must be `Object` and it must not
+declare any generative constructors.
+
+In practice, mixins are quite different from classes and it's uncommon for users
+to deliberately define a type that is used as both. It's easy to define a class
+without *intending* it to be used as a mixin and then accidentally forbid that
+usage by adding a generative constructor or superclass to the class. That is a
+breaking change to any downstream user that had that class in a `with` clause.
+
+Eventually, we would like classes to not be usable as a mixin by default. Being
+extensible and implementable seems to be the right default for classes based on
+Dart's history and talking to users. But being usable as a mixin by default is
+rarely (but not *never*) useful and often confusing. It makes classes brittle
+for little upside.
+
+Instead, under this proposal we require authors to explicitly opt in to allowing
+the class to be used as a mixin by adding a `mixin` modifier to the class:
+
+```dart
+class OnlyClass {}
+
+class FailUseAsMixin extends OtherSuperclass with OnlyClass {} // Error.
+
+mixin class Both {}
+
+class UsesAsSuperclass extends Both {}
+
+class UsesAsMixin extends OtherSuperclass with Both {} // OK.
+```
+
+This change is guarded by a language version. Any class declaration in a library
+whose language version is before the one this feature ships in can be used as a
+mixin as long as the class meets the mixin restrictions. Classes in libraries
+whose version is later than that must be explicitly marked `mixin class` to
+allow the class to be used in a `with` clause.
+
+When upgrading your library to the new language version, you can preserve the
+existing behavior by adding `mixin` to every class declaration that can be used
+as a mixin. If the class defines a generative constructor or extends anything
+other than `Object`, then it already can't be used as a mixin and no change is
+needed.
 
 ## Syntax
 
 This proposal builds on the existing sealed types proposal so the grammar
 includes those changes. The full set of modifiers that can appear before a class
-or mixin are `abstract`, `sealed`, `base`, `interface`, and `final`. Some
-combinations don't make sense:
+or mixin are `abstract`, `sealed`, `base`, `interface`, `final`, and `mixin`.
+Some combinations don't make sense:
 
 *   `sealed` implies `abstract`, so they can't be combined.
 *   `sealed` implies non-extensibility, so can't be combined with `interface`
@@ -422,9 +471,13 @@ combinations don't make sense:
     `final`.
 *   `base`, `interface`, and `final` all control the same two capabilities so
     are mutually exclusive.
+*   `mixin` as a modifier can obviously only be applied to a class. It can be
+    combined with any other modifiers that can be applied to a class.
 
 The remaining valid combinations are:
 
+<table><tr><td>
+
 ```
 class
 sealed class
@@ -435,14 +488,34 @@ abstract class
 abstract base class
 abstract interface class
 abstract final class
+```
+
+</td><td>
+
+```
+mixin class
+sealed mixin class
+base mixin class
+interface mixin class
+final mixin class
+abstract mixin class
+abstract base mixin class
+abstract interface mixin class
+abstract final mixin class
+```
+
+</td><td>
 
+```
 mixin
 sealed mixin
 base mixin
 interface mixin
 final mixin
 ```
 
+</td></tr></table>
+
 The grammar is:
 
 ```
@@ -452,36 +525,47 @@ classDeclaration ::=
   '{' (metadata classMemberDeclaration)* '}'
   | classModifiers 'class' mixinApplicationClass
 
-classModifiers ::= 'sealed' | 'abstract'? ('base' | 'interface' | 'final')?
-
-mixinDeclaration ::= mixinModifiers? 'mixin' identifier typeParameters?
+mixinDeclaration ::= mixinModifier? 'mixin' identifier typeParameters?
   ('on' typeNotVoidList)? interfaces?
   '{' (metadata classMemberDeclaration)* '}'
 
-mixinModifiers ::= 'sealed' | 'base' | 'interface' | 'final'
+classModifiers ::= ( 'sealed' | 'abstract'? typeModifier? ) 'mixin'?
+mixinModifier ::= 'sealed' | typeModifier
+typeModifier ::= 'base' | 'interface' | 'final'
 ```
 
 ### Static semantics
 
 It is a compile-time error to:
 
 *   Extend a class marked `interface` or `final` outside of the library where it
-    is defined.
+    is declared.
 
 *   Implement a type marked `base` or `final` outside of the library where it is
-    defined.
+    declared.
 
 *   Extend or mix in a type marked `base` outside of the library where it is
-    defined without also being marked `base` or `final`. *This ensures that a
+    declared without also being marked `base` or `final`. *This ensures that a
     subtype can't escape the `base` restriction of its supertype by offering its
     _own_ interface that could then be implemented without inheriting the
     concrete implementation from the supertype.*
 
-*   Mix in a class marked `sealed`, `base`, `interface`, or `final`. *We want to
-    eventually move away from classes as mixins. We don't want to break existing
-    uses of classes as mixins but since no existing code is using these
-    modifiers, we can prevent classes using those modifiers from also being used
-    as mixins.*
+*   Mix in a class not marked `mixin` outside of the library where it is
+    declared, unless the class declaration is in a library whose language
+    version is older than the version this feature ships in.
+
+*   Apply the `mixin` modifier to a class whose superclass is not `Object` or
+    that declares a generative constructor. *The `mixin` modifier states that
+    you intend the class to be mixed in, which is inconsistent with defining a
+    class that can't be used as a mixin. Note that this means that the `mixin`
+    modifier becomes a helpful reminder to ensure that you don't inadvertently
+    break your class's ability to be used as a mixin.*
+
+*   Mix in a class whose superclass is not `Object` or that declares a
+    generative constructor. *Because of the previous rule, this rule only comes
+    into play when you use a class not marked `mixin` as a mixin within the
+    library where it's declared. When you do that, the existing restriction
+    still applies that the class being used as a mixin must be valid to do so.*
 
 A typedef can't be used to subvert these restrictions. When extending,
 implementing, or mixing in a typedef, we look at the library where type the