Lasse R.H. Nielsen

We have a very hard time getting agreement on what the canonical `==` implementation is. For structs I'd be happy with: ```dart /// Use some efficient hash for the runtime...

As long as a stand-along identifier is interpreted as a type, not a name, I think allowing names should be safe. It matches function types, where we also allow names...

The "exact" type already exists in Dart in certain places - the type of a literal or object creation expression may have an exact type, which is why `List l...

With declaration site variance, you can't write `List list = ...`. That's *use-site* variance. If `List` is declared as `List` then it's invariant, so `List list = [1, 3, 5];`...

@Silentdoer I'd say that the `covariant` example would not be allowed. The `covariant` keyword allows a parameter to (unsoundly) be a subtype of the superclass method's parameter. It's unsound relative...

@Silentdoer It's not yet specified what happens to existing classes, or whether variance is applied implicitly. It may be possible to keep classes "unsafely covariant" (like now). If not, the...

I'd be happy with this. A type that occurs verbatim in the source code is canonicalized, even when passed through type variables. I'm not sure it's viable. It assumes some...

I'd be very wary about requiring canonicalization of run-time allocated values of any kind. That has a risk of memory leaks by keeping the canonical value alive for too long....

For the `enum` option, 2.17 also allow `enum`s to extend other classes: ```dart enum Colors extends Color { red(0xFFFF0000), blue(0xFF0000FF), // ... purple(0xFFFF00FF), ; const Colors(super.rgba); } ``` No need...

Damnit, my bad. You can implement an interface, and apply a mixin, but an `enum` can't extend another class than `Enum`.