Lasse R.H. Nielsen

> and if you stuff NaNs in there, you get exactly the pain that you have brought upon yourself. The issue is that *we* have to decide which pain that...

Not impossible, but I'd prefer `this.a` to `super.a`. After all, the invocation it's put into is a `this(...)`, not a `super(...)`. Can still be confusing that `this.a` initializes a field...

The current augmentation syntax is just `augmented()`, with no `super`. We could introduce a new contextual keyword, like `forward.x`, which makes sense for a forwarding constructor. We can use `this.x`...

I wouldn't say that `;` introduces an empty body. For constant generative constructors, you have to write `;` because you are not *allowed* to have a body. It would be...

True. In my example, the new constructor is more like a replacements, that calls the original somehow. Not consistent with how other augementations work. Augmentations have ... two? three? ......

The way augmentations are currently specified, I agree that anything that changes what you can *and cannot* do with a declaration is not a good fit. So no adding `const`...

> IMO we should treat augmented constructors similar to a `: super(..)` call ; kind of like `: this()`. The problem with that is that invoking the augmenting constructor means...

There is one issue with making variables created inside `do` loops visible in the condition: ```dart int x = 0; do { if ((++x).isEven) continue; var mod3 = x %...

I usually call these declarations "mixin application class" declarations. Using just "mixin class" gets confusing now we also have `mixin class` declarations. > not actually introducing a new class `A`...

> By the way, a mixin application class declaration like `class B = A with M implements I;` is specified to denote a regular class declaration It's denoting a regular...