Lasse R.H. Nielsen

If it had been: ```dart int value; int? bad() { return value = id(42); } ``` then "clearly" the compiler should prefer the more precise `int` from `value`. If it...

Agree. Recently wished I had `while`-`case`. But just allowing `case` as a general expression, with scope extending to the dominated true branch if used as a condition, would give us...

EDIT: I thought initializing formals were handled during biding-actuals-to-formals, but they aren't today, so what I suggest is actually exactly what we do today, just allowing instance variable initializers to...

The "Proposal 1" could work. Quick question: Can I do: ```dart class C(int x, int y) {} augment class C { final int x, y; new(this.x, this.y); new.swapped(this.y, this.x); }...

Good summary of the options. For 1D, it presumes that you *can* have field initializers referring to primary constructor parameters of an incomplete declaration, without making it a complete declaration,...

> This part is pretty spooky to me. It requires adding another phase to instance creation It's not so much a new phase, as it's reordering things that already happen....

> You're right, we need to specify the order that field initializers run when they may be spread across multiple augmentations. Filed: https://github.com/dart-lang/language/issues/4573. That's not so much what worries me....

I like and agree with almost all of this. My only quip is that I would prefer to primary constructor to not need to be introduced in the introducing declaration...

> earlier declarations in an augmentation chain should not imply that something is possible, if it is made impossible by a later declaration in the augmentation chain I only consider...

Would be nice, but needs to be specified as something different than "accessing the getter". Both because there might be a getter returning a different value, and because you cannot...