Named `_p` is augmented by `p`?

[eernstg]

The augmentations feature specification states that an augmenting declaration matches the augmented one only when (among other things):

• It has the same set of named parameter names as the introductory declaration.

It is an error for an augmenting declaration to fail to match the introductory declaration.

The private named parameters feature specification states that a named formal parameter whose name is private is a compile-time error unless the parameter is initializing (e.g., this._p) or declaring (e.g., final int _p or var _p):

If a user tries to put _ before a named parameter that isn't an initializing formal or declaring parameter, it's an error.

At the same time, it is an error for more than one declaration in an augmentation chain declaring a constructor to be complete, and an initializing as well as a declaring formal parameter makes the declaration complete, no matter what else it contains.

So, apparently, we can't augment an initializing or declaring named formal parameter if its name is private, and similarly for initializing formals. For example:

class C({final int _p}); // OK.

augment class C {
  // One attempt.
  new({@metaSomething int _p}); // Error, bad parameter name.
  // Another attempt.
  new({@metaSomething int p}); // Error, the parameter name does not match.
}

The "another attempt" approach seems to be somewhat in line with the treatment of super parameters, but apparently we will need to change a few words in a specification document in order to allow it.

@dart-lang/language-team, WDYT?

[lrhn]

I agree we need to change some words. Maybe insert a lot of them.

I don't think the parameter's name is private. But that's ambiguous because "parameter" means more than one thing.

We need to be very careful about the distinction between a parameter declaration, parameter signature (per augmentation and in total), parameter variable and just plain parameter (if such a thing exists).

A declaring parameter declaration with a private name identifier introduces a parameter signature which has a public name and an initializer list scope variable which has a private name (and also an instance variable).

Augmenting declarations must have a signature that matches the signature they're augmenting.

Goes for initializing formals too.

(A "parameter" cannot be declaring, that's only something a parameter declaration can be. Or that's what I think.)

[eernstg]

It might suffice to specify that the names in an augmentation chain for a named formal parameter can be zero or more occurrences of p for some public identifier p, plus zero or more occurrences of _p (at most one would work, too). Existing rules about individual parameter declarations would then suffice to reject all the combinations that we do not wish to support. For example, a named parameter which is declared with the name _p must be initializing or declaring, and we can't have two or more of those in the same augmentation chain; moreover, an initializing formal parameter must be in the parameter list of a non-redirecting generative constructor, and a declaring one must be in the parameter list of a primary constructor, etc.

(I'd say that a "formal parameter" could mean a formal parameter declaration, or an entity which is the semantics of one or more formal parameter declarations. The declaring entity would be the latter, and exactly one of the former may imply that the latter is declaring, whereas all the other declarations are neutral in this respect.)

[Edit: Removed references to _ because this is about named parameters, and they can't use the "don't care" name _ that we can use in positional parameter augmentations.]

[lrhn]

I prefer to be precise over "correct just because the things we don't say have other errors".
Even if errors have an implicit order, so some thighs won't be checked until something else definitely has no error (like subtyping not making sense of the class hierarchy has cycles), I'm not sure where augmentations for into that.

We should probably figure that out, and make sure where I'll were consistent.

Are augmenting declarations entirely syntactic, or do they, in combination, introduce a synthetic "declaration", which then introduces a member?

What even means "declaration" these days!?!

Maybe we should be defining things not by the individual syntactic declarations, but on the entire set ("chain") of declarations of the same name.

If that entire set of same-name-declaring declarations is not consistent, then it's a problem for the set, which is invalid in is entirety.