Erik Ernst

Perhaps the title of this issue should be 'Should concrete structs support sub-classing?'? With that, I believe everybody agrees on "No!" (at least until now ;-).

I think two models are promising: 1. `implements` reveals types held by the underlying representation, the extension struct type is a subtype of everything it implements, and overriding a method...

> my starting point would be that we not provide this functionality. If we leave out everything about `implements`, and we leave out everything about boxing, then we have a...

I would very much support having immutable struct entities, with no guaranteed identity, and supporting structural comparison (presumably by means of an operator `==` whose implementation is provided automatically, with...

I took a look at the different levels in the [initial comment](https://github.com/dart-lang/language/issues/2020#issue-1074038750), and I think there's a need to make a couple of small adjustments, or at least clarifications. ####...

About this design point: > To make this sound, we only need to make one breaking change to the > language: Don't delegate private names to `noSuchMethod`. We do need...

> My personal opinion is that I'd prefer to steer users away from doing `identical` on records Certainly! I would expect the implicitly induced operator `==` on record types to...

Yes, please! ;-) We could use the following rule: The primary constructor of a struct declares non-late instance variables that are final by default. The primary constructor of a class...

This would be a run-time error, plus a compile-time error in the cases where the situation can be detected statically? For `WeakReference`, could we allow the usage? Having extra copies...

A proposal specifically for union types in type parameter bounds (and nowhere else) might be useful. But if you're interested in union types in general, it's recommended that the discussion...