Augmenting primary constructors and instance variable initializer scopes.

[lrhn]

Primary constructors ships with the behavior that:

class C({final int _x = 0}) {
  this: assert(_x >= 0);
  final int y = _x + 1;
}

declares a constructor with a signature C Function({int x}) and _x + 1 is evaluated in the initializer list scope of that constructor which has a binding for _x.

For augmentations this raises the complexity of constructor overrides.

The currently proposed behavior is that:

class C({int x});
augment class C({final int _x = 0});

is valid since the first declaration's constructor is incomplete, and the two constructor declarations have compatible signatures. The _x is an "implementation detail".
However, that detail leaks.

You can write:

class C({int x}) {
  final int y = x;
}
augment class C({int x = 0}) {
  this: _x = x;
  final int _x;
}

and it will work, but, the second primary constructor declaration is complete (it has an initializer list).

However if you try to write:

class C({int x}) {
  final int y = x;
}
augment class C({final int _x = 0});

it won't work, because x in final int y = x; is not in the initializer list scope for the primary constructor, that contains _x.

The augmentation, written later and using an idiomatic instance variable declaring parameter (and valid by itself) introduces an error in the earlier class declaration.

Introducing errors in other fragments isn't special, that can happen with augmentations when everybody have to agree. What's annoying here is that they're not really disagreeing on what happens, only on how to refer to the constructor parameter, and only because one of them uses the supposedly helpful private-named-parameters feature.

Possible ways to handle this

1. Don't use the initializer list scope for instance variable initialziers. Instead use a scope derived from the parameter list of the primary constructor on the same fragment that contains the instance variable initializer. So the class declaration with C({int x}) would see x in that scope, the class with C({final int _x = 0}) would see _x.

   • It introduces a new scope. Per class declaration.
   • You can't (as easily) move field initializers between the field and an initializer list if they have different scopes. (But they don't if they're inside the same class declaration.)
   • It's an error to refer to the public name of a parameter in an initializer of a class fragment that doesn't have a primary constructor declaring that parameter with that name. (There is only one declaration which can possibly have a private-named parameter, since that's necessarily a complete declaration, and inside that class declaration field initializers can then refer to that private name, and not the public one.)

2. Say that C({int x}) not only introduces a signature, but also a name into the initializer list scope. It's then an error of another constructor introduces a different name into the initializer list scope, which effectively prevents any use of privately named parameters for that parameter. That's just the cost of doing augmentations.

   • We then allow incomplete declarations to use private names, so one could write a primary constructor C({int _x}) in the first fagment and refer to it in a field initializer as final int y = _x;. Then you'll have to provide a complete declaration with a parameter that is either this._x or final int this._x, that's the only way to have a complete implementation of that parameter.

3. Just allow every field initializer to refer to either the public or private name of the parameter, if there is any private name for it anywhere.

   • This is breaking for the current non-augmenting primary constructor behavior, where

     const x = 42;
     class C({final int _x = 0}) {
        final y = x + _x;
     }

     is valid and alllows x to refer to the top-level constant.

@dart-lang/language-team
I think 2 is the most direct approach, and I'll work on specifying that.

I think 1 is possible, more complex, but possibly more understandable to users
(You refer to a primary constructor variable by the name it has in the primary constructor
of the current fragment. For all but one fragment, that's the public name. You only refer to
it by the private name inside the one fragment which actually has a parameter with that
private name.)

[lrhn]

Having thought about this more, I now think option 1 has the best usability - fewest tricky corners and effects/restrictions-at-a-distance that users can trip over. So let's define it in more detail:

Proposal

The scope of instance variable initializer expressions in a class/enum declaration that has a primary constructor is
a new field initializer scope which is defined for each class/enum fragment (aka. introducing or augmenting declaration for the same element).

The field initializer scope for a fragment is almost the same as the initializer list scope (same parent scope, same number of entries with the same values, which are the arguments after applying the default values of the complete constructor declaration). The exceptions are:

• It uses the public name for all parameters of the primary constructor (as introduced by any declaration of that constructor).
• It's an error to refer to a parameter name in that scope if the surrounding class/enum fragment does not have a primary constructor declaration which has a declaration of that parameter with that name as identifier.
  • A class/enum declaration can not have a primary constructor parameter with a given identifier in three ways:
    • No primary constructor.
    • Parameter is positional and declaration uses _ instead of the name.
    • Parameter is named and declaration is private named declaring or initializing formal.
• If a class/enum fragment has a complete primary constructor declaration with a private named parameter, which is therefore definitely a complete declaration, then the field initializer scope uses the private name for that variable (and the public name is not in scope). It still contains entries for every parameter named by any declaration of the constructor.
  • This is not exactly the initializer list scope, because that only contains the parameters named by the complete constructor
    declaration, not the names only introduced by other incomplete declarations. (That's how function parameters work,
    so I expect constructor parameters too.)
    If the complete constructor names all parameters, then this scope is the same as the initializer list scope.
  • Alternative, but potentially breaking for existing single-declaration primary constructor code, the public name is in the scope and it's an error to refer to it.

This has the following benefits:

• If you don't use privately named parameters, it works exactly like using the initializer list scope.
• If you have no augmentations, it works exactly like the base primary constructor specification today.
  • Only worry is that you get no warning about trying to use the public name of a private named parameter, fx if you move a field from one fragment to another.
  • If we keep the public name in scope, and make it an error to refer to it instead of the private name, then it's a difference from the current no-augmentation primary constructor feature, which allows referring to an outer declaration with the same name as the parameter's public name.
  • Is protecting against that worth the break? If not, just use the compatible version.
• The primary constructor parameter names that you can use in instance variable initializers are always the ones you see in the primary constructor parameter list above you. Other public primary constructor parameter names are still in scope, and using them gives you an error telling you that you must declare them by name if you want to refer to them in this fragment..
• You can declare a (primary or non-primary) complete constructor with a private named parameter without affecting any other class/enum declaration for the same type. It's an implementation choice, and it only affects the one fragment it's in scope in. Using a privately named parameter is an implementation detail, it doesn't leak from the scope of that declaration.
• So you can safely write class C({int x}) { final y = x; } and trust that it works, and the author writing augment class C({final int _x = 0}); can also trust that they don't conflict with fragment about the public parameter named x. Only inside that one fragment do they know about, and need to use, _x.

Disadvantages include:

• Needs to introduce a new scope. (Only when it matters, if there is no primary constructor with a private-named named parameter, it makes no difference, all the scopes are the same as the initializer list scope.)
• The way you refer to parameter differes between fragments. But only in the one fragment that actually declares a private named parameter named _x. And there is a consistent rule: "use the name declared above".

I think that's a big win compared to option 2 or other approaches that get in the way of using private named parameters, same as I think augmentations shouldn't get in the way of using primary constructors. Both are core features of Dart now, and we expect people to use them everywhere. Restrictions based on feature interaction should be minimized.

• I think this will give users a more understandable behavior, even if it requires us to introduce a new scope for the instance variable initializers.

• It looks like lexical scope to users. Any exceptions (Parameter variables in scope, but not declared in this fragment) are early compile-time errors with understandable messages, so you can adapt - declare them to refer to them, rename them everywhere so you can refer past them, or rename the top-level you're referring to. Same thing you would do in a non-augmented class to get past a scope issue.

• The new-scope-per-fragment can be the same scope in every fragment that doesn't have a primary constructor with a privately named parameter, just with different local restrictions on which name can be accessed. An implementation doesn't have to bake the restriction into the scope. Then there are only two scopes: Field inintializer scope (public names of parameters) and initializer list scope (private name of parmeters, only in scope of the actual complete declaration that introduces it).

Can you still break another fragment?

Augmentations are still cooperative, you can break other fragments in many ways.

This way the choice of implementation of a constructor/instance variable does not leak between fragments.

Using option 2 above could easily lead users to the idea that "augmentations and privately named parameters don't work together". Which would arguably be correct - the constraints are global and writing the idiomatic class C({int x}) { final y = x; } now effectively prohibits privately named parameters in all fragments, whether you intended it or not. With option 1, as detailed here, that problem goes away.

Examples

(Only interesting examples, all the plain ones "just work".)

The one weird case is when you have a non-primary complete constructor declaration in the same fragment as an incomplete primary constructor declaration:

class C({int x, int y}) {
  augment C({final int _x = 0, final int _y = 0}) : product = _x * _y;
  final int sum = x + y;
  final int product;
}

In that case, and that case only, can you not move expressions between instance variable initializers and initializer list initializers in the same fragment, because they use different names for the same parameter.
So don't do that.

Otherwise each fragment can be written independently as long as they agree on the signature of the class and its members (aka. good abstraction and encapsulation).

When using a non-primary initializing constructor, whether with a primary constructor or not, the scope of its private named _x and _y is only the initializer list scope, and it doesn't extend beyond the non-primary constructor declaration. No field initializer uses the initializer list scope, they all use the field initializer scope which uses public names.

In a more-than-one-fragment example:

class C({int x, int y}) {
  final int sum = x + y;
}

augment class C({int x, int y}) {
  final int product = x * y;
  final int difference;
  augment C({final int _x = 0, final int _y = 0}) : difference = _x - _y;
}

Compared to:

class C({int x, int y}) {
  final int sum = x + y;
}

augment class C({final int _int x = 0, final int _y = 0}) {
  final int product = _x * _y;
  final int difference;
  augment this: difference = _x - _y;
}

Here the scope of the complete primary constructor's parameters is the class itself,
so both the initializer list (this: ...) and the instance variable initializers that are lexically in that scope.
Looks lexical!

(But see "initializer list" section below. They may still be different scope in some cases.)

The breaking change, if we choose to add the public name to all field initialzier scopes even when there is also a private name, would be:

const x = 42;
class C({final int _x = 0}) {
  final int y = x + _x;
}

This is valid 3.13 (primary constructors) code where x denotes the constant and _x the initializer list variable.
If we put x into the field initializer scope of this C fragment, then it stops being valid.

But adding x, and making it an error to refer to it, also protects against:

const x = 42;
class C({int x}) {
  // final int y = x; // Moved to other fragment
}
class C({final int _x = 0}) {
  final int y = x; // Moved from other fragment, now different behavior.
}

I would want that protection, but it is breaking.
(I don't expect we can change primary constructors to making it an error for an initializer expression to use the public name of a private named constructor ... not before launch.)

That said, you can't always assume you can move declarations freely between fragments, not when they refer to names outside of the declared class/enum. If nothing else then when we get enhanced parts ("parts with imports"), the import scope isn't necessarily the same everywhere in a library.

Initializer list scope, what is actually in it?

Does the initializer list scope contain entries for names not declared by that constructor declaration,
or not.

The field initializer scope is not precisley the initializer list scope if the initializer list scope is defined only from the parameters of the complete constructor declaration:

const x = 42;
const y = 37;
class C {
  final int z;
  C(int _, {final int _y = 0}) : z = _y + x + y { // Both x and y refer to top-level constants.
    print(x + y);
  }

  f(int _) => x + y; // Refers to top-level constants.
}
augment C(int x, {int y}) {
  final int w = x + y; // Both refer to parameters.
  augment f(int x); // Does not affect scope inside `f` implementation.
};

Here the field initializer scope for the second declaration of C contains x and y from its parameters.

The initializer list scope of the actual constructor implementation does not have an entry for x.
Not unless we say that it does. We could do that, because there is no existing code with augmentations,
so an existing C(int _, ...) won't have any name for the first parameter elsewhere.
And if we do that, then we would probably make it an error for the complete constructor declaration to refer to x,
in which case the initializer list scope is the same as the field initializer scope for that fragment.
But that would be inconsistent with what we do for functions, where the name of undeclared parameters
are not shadowing the lexical scope. And it would only be the initializer list scope, it should not affect the constructor
body scope, so it's extra inconsistent.

I think it's safer to keep the field initializer scope and initializer list scope separate,
with the former having all named parameters from the defined function signature,
and the latter, being an actual invocation scope of the constructor implementation,
having only the actual parameters defined by the complete constructor itself.

[munificent]

I really appreciate you thinking through all of this, but I can't help a little voice in my head screaming that this is all way too much complexity for the benefit in return. We have such a jumbled pile of features that are sort of syntactic sugar:

• A primary constructor (and its optional initializer block) is sugar for an in-body constructor.
• A field declaration whose initializer refers to a primary constructor parameter is sugar for an explicit initializer list entry.
• Augmentations are sugar for the merged declaration.
• Private named parameters are sugar for a parameter and an explicit initializer.
• Initializing formals are sugar for a parameter and an explicit initializer.
• Declaring parameters are sugar for a field declaration, a parameter, and an explicit initializer.

(In all of these bullet points, insert "mostly" before sugar if there are funny corner cases I'm omitting.)

The only fundamental concepts are:

• Declaring an instance field.
• Declaring a constructor parameter.
• Initializing an instance field.
• Executing a constructor body.

I don't think we should specify this feature in terms of desugaring, but I do think we should be able to reason about it terms of that. In particular, I think the static semantics should be the same both pre- and post-desugaring.

Here's what I mean by that. Here's a chain of logic:

1. We say that with augmentations, only one declaration can be complete.

2. We say that an initializer list makes a constructor complete.

3. We allow a field initializer in a class with a primary constructor to refer to the primary constructor parameters.

   class C(int x) {
     int y = x;
   }

4. And we say the semantics of (3) are more or less the same as if you desugared that field declaration to an explicit initializer list:

   class C {
     int y;
   
     C(int x) : x = y;
   }

5. But then we don't say that a field initializer that refers to a primary constructor parameter makes the constructor complete.

I think (2) and (5) are at least part of where we have gone astray.

If we're going to have a lot of syntactic sugar features, I think the only way to tame the complexity of their interactions is to be rigorous about having their semantics consistent with the semantics you would get after desugaring. Again, I'm not saying we specify it that way. But we should do our homework such that the specifications are consistent with that.

Here, that would mean that a field initializer that refers to a primary constructor parameter forces the constructor to be complete. That means:

class C({int x}) {
  final int y = x;
}

augment class C({int x = 0}) {
  this: _x = x;
  final int _x;
}

This is an error now. You've got two complete constructor declarations.

class C({int x}) {
  final int y = x;
}

augment class C({final int _x = 0});

And this is an error too. The semantics are the same (error) for both using the private named parameter and using what a private named parameter desugars to.

Likewise, they are consistent with the semantics if you didn't use a primary constructor:

class C {
  C({int x}) : y = x;
  final int y;
}

augment class C {
  C({int x = 0}): _x = x;
  final int _x;
}

Again, error.

I'm really worried about the overall complexity of the language. If we want to keep adding brevity syntactic sugar features—and all evidence is that we do—then I think the only way to avoid exponential complexity from their interactions is by being very rigorous about defining their semantics to be consistent with a desugared form.

I admit, it is possibly confusing for users that some field initializers make a primary constructor complete and others don't. But that's a tolerable annoyance, I think.

[scheglov]

One complication with making this into a complete constructor:

class C(int x) {
  int y = x;
}

...is that it stops being a purely syntactic property, like: you have this.foo, or super.foo, or final int foo.
You have to resolve references to identifiers.
Not unsolvable, we can move it from PrimaryConstructorDeclaration to the corresponding ConstructorFragment.

[lrhn]

@munificent

... a little voice in my head screaming that this is all way too much complexity for the benefit in return

Maybe it is. I have a feeling that it's because you're looking at it from a perspective where you have a set of complexities already, and you try to fit this onto that complexity. When it doesn't fit, it looks like the XOR of the two domains, which is more complicated than either by themselves.
Or maybe I've looked at this so long I can't see the complexity any more. Also a possibility.

A primary constructor (and its optional initializer block) is sugar for an in-body constructor.

I'll stop here.

I expect that to most users, after a short while, primary constructors are how (initializing) constructors are written, and in-body initializing constructors is a technical thing you can use when the real constructor doesn't work for some reason. Or you want to have two, but I'll expect most of those will end up with two factory constructors forwarding to a private primary constructor.

I believe that's what @mit expects/wants to happen. (Do say if I'm misrepresenting you here, Michael!)

So this is how you write a Point class:

class Point({
   required final double x,
   required final double _y,
}) {
  final int _squaredDistanceFromOrigo = x * x + y * y;
}

This is the fundamental operation to users. Not the desugaring we make (or don't make) behind the scenes.

If someone starts from there, and try to understand augmentations, then anything that makes primary constructors or field initializers into second-class citizens will feel completely counter-intuitive, as if augmentations do not fit the language, and it's trying to fit the primary syntax into some obscure technical hole where it doesn't fit.

I want to make primary constructors and field initializers as easy to use as possible with augmentations.
Because otherwise it'll feel like augmentations are badly designed.

I'm sure that's not the view of everybody, but I do feel quite strongly about it. :)

Here's what I mean by that. Here's a chain of logic:

 1. We say that with augmentations, only one declaration can be complete.

That's a simplification from where we started. It's a good simplification.
Being complete means introducing code that does something at runtime.
If there is only one place that happens, we don't have to worry about ordering.
So yes.

 2. We say that an initializer list makes a constructor complete.

Because it contains code that does something at runtime. It's part of the constructor, so it has to be.
(Although I have defined consistent rules for combining constructors, before the "one complete declaration" choice.)

 3. We allow a field initializer in a class with a primary constructor to refer to the primary constructor parameters.

class C(int x) {
  int y = x;
}

 4. And we say the semantics of (3) are more or less the same as if you desugared that field declaration to an explicit initializer list:

class C {
  int y;

  C(int x) : x = y;
}

Yes and no. Mostly no.

If you write a class today:

class C {
  static int _counter = 0;
  final int v1 = ++_counter;
  C(this.v3) : v4 = ++counter;
  final int v2 = ++_counter;
  final int v3;
  final int v4;
}

then we don't say that field initializers work by desugaring to initializer list entries. We could have, at any time, but we have never taken that step. They are not "put into the initializer list" at some point, they supposedly happen before the initializer list is processed.
(Technically they can happen before binding actuals to formals. I don't know if it's possible to make that step throw, so we can tell.)

The pre-primary constructor initializers also don't have access to parameters, so it doesn't matter that much, but the variables here are initialized in the order v1, v2, v3 and v4. (You can't tell when v3 is initialized because you can't access it until they're all initialized, and it can't have a value that depends on mutable state, but that's the specified order.)

 5. But then we don't say that a field initializer that refers to a primary constructor parameter makes the constructor complete.

And that's also something I feel strongly about.
I don't want users to have to think in terms of desugaring.
Primary constructors and field initializers are first class features that work, and can be understood, independently of initializer lists.

Take this class:

class C {
  static int _counter;
  final int x = ++_counter;
}

This is a valid class today. It declares no constructor. It will get a "default constructor" which we have consistently said
is C();, aka C(): super();. There is no initializer list, and no user has ever thought there was a secret initializer list in the default constructor.

Now add augmentations. If I add:

augment class C {
  final int y = ++_counter;
}

should that be valid?
(Heck yeah! I can't give a reasonable argument why it shouldn't be.)

There is still no constructor declaration. Neither fragment gets an implicit default constructor declaration.
The default constructor is an element (in analyzer terms) added when we recognize that there is no constructor declaration anywhere.

The fields, and their initializers, exist independently of whether there is a constructor with an initializer list.

Then we take the next step and add:

augment class C(final int z) {
  final w = z + 1;
}

This is a complete constructor.
Is it a problem that the prior fragments had fields with initializer expressions?
(Shouldn't be. But then, they don't refer to primary constructor parameters.)

I think (2) and (5) are at least part of where we have gone astray.

I do think that the design I'm aiming for is better for users, by having fewer exceptions.
I actually think it's less complicated than anything else we've tried, which had (arbitrary-seeming to a user) restrictions on what you can do.

Every time we say "you can't do this if you also do that", we are adding complexity, and I believe we are adding it in a way that's much harder to remember and work with than just having a single complicated feature that works everywhere.

• A class can have one primary constructor (and if so, no other initializing constructors). That's already the case.
  • Having a primary constructor is a property of the class, more than it is a property of the constructor.
• Every augmenting or introducing declaration is either incomplete, in which case introduces signature, but no behavior, or complete, in which case it also introduces behavior. At most one can be complete. Also nothing new.
• An initializing constructor can be written either as primary or non-primary. It does not change the signature, but if there is at least one primary constructor declaration for it, that's the primary constructor of the class, and it's definitely initializing.
• If a class has a primary constructor, instance variable initializers can refer to its parameters by name.
• As a help to avoid confusion, if your field initializers refer to a primary constructor parameter, the containing declaration must have a primary constructor declaration with a name for that parameter. That's the name you use, and it makes it look more like lexical scope.
  • If, and only if, that primary constructor used a private named parameter, that means the name you use is the private name.

I think that's the short, but surprisingly complete, summary of augmentations, primary constructors and field initializers as I propose them.

Anything that introduces exceptions will likely be more complicated. (Or I see it as such because it doesn't fit my model, which has been molded after looking at this for quite some time.)

I admit, it is possibly confusing for users that some field initializers make a primary constructor complete and others don't. But that's a tolerable annoyance, I think.

It's an exception! 😉
I think it's better without it.

But TL;DR: Instance variable initializers are not part of the constructor. They are separate today, and I want them to stay that way with augmentations. To make that work, having a primary constructor is a property of the class, and the field initializers of the class can refer to its primary constructor parameters.

If you start from that view, I'm not seeing the complexity that comes from trying to fit that into constructors and initializer lists.

Then the actual implementation of the initializing constructor only has to receive the argument list and fill in default values, then it can leave it to the class to initialize instance variables with those values for the primary constructor variables, before coming back and executing the constructor itself.
(Which is slightly more work than before primary constructors where the instance variables were initialized before binding actuals to formals. But not much.)

[lrhn]

One complication with making this into a complete constructor:

We can rephrase that:
If the declarations of a class contains a generative constructor declaration with no complete declaration, that constructor gets a default initializing implementation which:

• has normal parameters corresponding to the combined signature.
• has no initializer list entries.
• invokes the unnamed superclass constructor with no arguments.
• has no body.

Basically the normal default constructor, just maybe with parameters.

If that's easier, let's just do that.
It's more direct too.

(And checking the spec, it's basically what it says: If there are declarations for a generative constructor, but no concrete declaration, the class gets an implementation of that constructor which does nothing other than accept arguments and call super().)

[munificent]

But TL;DR: Instance variable initializers are not part of the constructor. They are separate today, and I want them to stay that way with augmentations. To make that work, having a primary constructor is a property of the class, and the field initializers of the class can refer to its primary constructor parameters.

If you start from that view, I'm not seeing the complexity that comes from trying to fit that into constructors and initializer lists.

OK, I am persuaded. I was trying to have as few semantic concepts as possible and felt that reducing instance field initializers to initializer list entries would help. But maybe that's more trouble than it's worth.

In that case, there is still inconsistency but now in the other direction. Consider:

class A(int x) {
  int x = x;

  augment A(int x) { print('hi'); }
}

class B(var int x) {
  augment B(int x) { print('hi'); }
}

I believe in the current specification plus what you propose, A is fine but B is an error. With A, since the field x is initialized in its own initializer, we don't consider that to make the constructor complete and thus the augmenting declaration that provides a body is OK.

In B, we have specified that a field parameter implicitly makes a constructor complete (because we think of it as a synthesized initializer list entry and not a synthesized field declaration initializer). But we could just as well say that field parameters are interpreted as synthetic instance field declaration initializers. In that model, then, it would imply that a field parameter doesn't make the constructor complete.

I don't think it makes sense to allow A and not B. We should allow either both or neither.

Further:

class C(int y) {
  int y = y;
  augment C(int y) { print('hi'); }
}

class D(this.y) {
  int y;
  augment D(int y) { print('hi'); }
}

class E {
  int y;
  E(this.y);
  augment E(int y) { print('hi'); }
}

Again, we currently say that C is fine but D and E are not. If field declaration initializers are fundamental and don't induce a constructor to be complete, it seems that we should lean on them as much as possible. I can't think of a good reason to allow C but forbid D. And if we allow D, it seems weird to prohibit E.

Honestly... maybe the notion of "complete" and "incomplete" is what's giving us so much trouble? Even with it, we still have to specify an ordering for augmentations, so it doesn't buy us that much.

Maybe the simpler proposal is to say that augmentations can do whatever they want and:

• If two augmentations add initializer list entries, they are concatenated.
• If two augmentations add unrelated field declarations with initializers, they are both added to the class and the initializers run in augmentation application order.
• If two function/method/constructor augmentations add a body, the later one replaces the former. That's consistent with how it would behave if we later add augment super() but you don't call it.
• If two augmentations of the same field/variable both have an initializer, the later one replaces the former.
• As you say, if any fragment wants to have add a field with an initializer that refers to a primary constructor parameter, it must have a primary constructor declaration with that parameter name.
• A primary constructor with a field parameter is treated as a constructor declaration and a field declaration with an initializer that accesses the constructor parameter.
• A constructor with an initializing formal is treated as a constructor declaration and an augmentation of the corresponding field that adds a initializer that accesses the parameter. (It is given the magic ability to do this even if the constructor isn't primary so the parameter isn't actually in scope in the field initializer.)
• Further, we remove the rule that restricts private named parameters to initializing formals and field parameters. Any parameter can be a private named parameter. (We probably do want a lint that yells if you use one unnecessarily, or allow the existing "no underscore for local variables" lint to handle it.)

The last three rules mean that two declarations of the same constructor are able to freely mix normal parameters, initializing formals, field parameters, and private named parameters:

class C(final int a, int b, {required int c}) {
  int b;
  int _c;

  augment C(int a, this.b, {required int c});
  augment C(int a, int b, {required this._c});
}

Or even:

class C({required final int a}) {
  augment C({this.a});
  augment C({int a});

  int _a;
  augment C({required this._a});
}

This would not erroneous. There are two redundant initializers for a, the first of which is discarded. The same parameter also initializes _a.

An initializing formal, field parameter, or private named parameter affects the initializer of the corresponding field, but has no effect on the signature of the constructor for augmentation purposes.

This would be, I think, strictly more expressive, and simpler. The main thing you lose is that it's possible to replace a body and drop code on the floor without really realizing. But... just don't do that.

[lrhn]

Consider:

class A(int x) {
  int x = x;
  augment A(int x) { print('hi'); }
}
class B(var int x) {
  augment B(int x) { print('hi'); }
}

I believe in the current specification plus what you propose, A is fine but B is an error.

Yes.
Both A and B have two declarations of their unnamed/new constructor.
In A the first declaration is incomplete and the second declaration is complete because it has a body.
In B both are complete, one because it has a declaring parameter, and one because it has a body.

That does mean that an instance variable with an initializer is not the same as a declaring parameter.

To me, a declaring parameter is the same as a variable declaration and an initializing formal, and an initializing formal makes a constructor complete too, so that's consistent.

But we could just as well say that field parameters are interpreted as synthetic instance field declaration initializers

True. And maybe we should. The biggest problem with that is that if a declaring parameter does not make a constructor complete, it's part of the class declaration/initialization, not the constructor, then you are not limited to one constructor declaration having initializing formals.
Any primary constructor could write a declaring formal for a parameter, but at most one of them because they're also declaring the instance variable, and you can only have one of those.

Well, except private named parameters. You could technically write:

class C({final int x});
augment class C({final int _x});

I really feel like the constructor declaring the private named parameter should be complete, because it's declaring the name of a local variable ... but that's circular reasoning. It's only declaring a local variable if it's complete. Otherwise it's declaring an instance variable and constructor signature.

It could work. It could be harder to explain. Or maybe it's easier, if it's done right.

It is inconsistent that some ways to initialize an instance variable counts as constructor-parts and some do not.
At least the ones that does are the ones that are part of the actual constructor syntax.
It still makes the ones that are not part of the constructor be better in every way — except needing to write the name three times.
If only we had a way to do that without repeating the name! 😁

... same with initializing formals ...

True. Each primary constructor declaration could do its own "initialize variables based on arguments", even variables it didn't declare itself.
But at that point ... it feels like it's starting to be a constructor, not just a constructor signature.

It would be more symmetric.

• A declaring parameter is the same as a variable declaration and an initializing formal.
• An initializing formal is the same as an instance variable initializer referring to the parameter.

It would allow:

class C {
  C(int x, int y) : sum = x + y; // Much complete!
}
augment C(final int x, final int y); // Me wanna store the values!

written directly like that, without having to rework it as:

augment C(int x, int y) {
  final int x = x, y = y;
}

• If two augmentations add initializer list entries, they are concatenated.

They are executed in some order. I'd say source order. ("Concatenated" sounds like source transformation. There is no transformation, the semantics is defined on the sources that exist.)

Also at most one constructor declaration can have a super-constructor invocation, and that's the only one that can contain super parameters.

• If two augmentations add unrelated field declarations with initializers, they are both added to the class and the initializers run in augmentation application order.
• If two function/method/constructor augmentations add a body, the later one replaces the former. That's consistent with how it would behave if we later add augment super() but you don't call it.

Should not be replaced, that's too ... useful, but hard to reason about. If the code is there, it is real and will be executed.

They can all be executed in ... source order? reverse source order, to be the reverse of the initializer list order?
Probably source order.

• If two augmentations of the same field/variable both have an initializer, the later one replaces the former.

I'd say no. There can still only be one implementation of anything. You can only initialize a variable once.
If you try to do it twice, it's an error.
One declaring parameter, one initializing formal, one initializer list entry or one initializer expression. Two is a conflict.

• As you say, if any fragment wants to have add a field with an initializer that refers to a primary constructor parameter, it must have a
  primary constructor declaration with that parameter name.
• A primary constructor with a field parameter is treated as a constructor declaration and a field declaration with an initializer that accesses the constructor parameter.
• A constructor with an initializing formal is treated as a constructor declaration and an augmentation of the corresponding field that adds a initializer that accesses the parameter. (It is given the magic ability to do this even if the constructor isn't primary so the parameter isn't actually in scope in the field initializer.)
• Further, we remove the rule that restricts private named parameters to initializing formals and field parameters. Any parameter can be a private named parameter. (We probably do want a lint that yells if you use one unnecessarily, or allow the existing "no underscore for local variables" lint to handle it.)

That last item would mean that a named parameter can always have a private name in the initializer list scope, even if it doesn't refer to a privately named instance variable. Sure. Can we make it work for positional parameters too? 😉

This is all possible.
It's a lot. (And it's still not as far-reaching as #4063.)
It contradicts the "only one implementation" story we have for everything other than constructors, but that might still be the right thing, or at least allowing some part of it.
I have been worried about a fragment wanting to introduce an instance variable, and not being able to initialize it.
I do like the simplicity of "one implementation only", but augmenting class declarations can extend a class with state, so it should also be able to initialize that state. Otherwise it's hamstrung. (That's another reason instance variable initializers should work in every fragment, and not be linked to the complete constructor.)

There is a problem with allowing too much of this in constructors in general, because if there is no primary constructor, then there can be more than one initializing constructor, and then you need to add initialization to all of them. You can't add state and initialize it using an initializer list entry if you don't know all constructors. That's going to be painful.
So maybe restrict non-complete-constructor class declarations to only be able to initialize variables using a primary constructor, and then ... it could probably be restricted to instance variable initializer expressions, plus initializing formals and declaring formals for brevity.
(And maybe a body, if the variable needs post-this-initialization. And maybe an initializer list just for an assert. ... and here we go again!)
But only primary constructor declarations can do that, because you can only do it if you have a primary constructor, and using a primary constructor to do it will ensure that you do.