Lasse R.H. Nielsen

This can only affect *dynamic* invocations, right? A statically allowed typed invocation should not be able to fail the type check. It may fail the implicit downcast on any given...

(I personally wish for that to keep working: https://github.com/dart-lang/language/issues/3576, but haven't seen any decision about it.)

It's an interesting idea that I've been thinking about for a while. There is a difference between *forwarding* and *delegation*. In the latter, the `this` object during the call will...

I'd rather give mixins constructors. Something like https://github.com/dart-lang/language/issues/1605#issuecomment-1543650950 That's how you initialize an object. Doing it after the object has been created risks a worse design (fields not `final` that...

If we add constructors to mixins, you would also get a way to call them (and probably be *required* to call them) in the subclass constructor. Obviously if getting the...

> But when an instance of B is created, if the ctor of A is calling ´getValue()´ it will call B.getValue but at this point, the ctor of B hasn't...

Sure, a third phase will solve this problem. Until someone comes up with a problem that requires a fourth phase. Eventually we'll want our generative constructors to be able to...

I can see that a third phase here will solve your problem. I don't necessarily believe that your problem is common enough that it warrants a language-based solution. I'm also...

I'd be fine with allowing `interface` not followed by `class` to be a shorthand for `abstract interface class`. (Heck, I've suggested it before myself.) I don't see any advantage in...

From the general rule of augmentations not changing signatures, an augmentation should not be allowed to add an initializer to a `late final` variable that has none. A `late final`...