[Declaring Constructors] Feature specification

[kallentu]

Issue for tracking the status of the feature specification.

• This issue won't be closed until the feature is almost done in case there are issues that incite changes in the spec.

The working spec is located here: https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md

Work Items

Nothing yet. Will add as needed.

Related PRs

Update declaring constructors to allow the new constructor syntax - dart-lang/language#4543

• https://dart-review.googlesource.com/c/sdk/+/456640

[RohitSaily]

in the grammar it is permissible to specify a declaring formal parameter with var and its type eg for <declaringSimpleFormalParameter>. normally in dart code var_and_type is enforced so that var cannot be used when the type annotation is specified eg

class A
{ var int a; // ERROR `var_and_type`
}

should the grammar be consistent with this or is this a concern of tooling and not relevant to the specification?

[eernstg]

That's crucial, and it's definitely part of the specification: The keywords var and final determine that the given formal parameter is declaring. When neither of those keywords is present, the formal parameter is just a regular, non-declaring formal parameter, but when the keyword is present it is a declaring formal parameter. This in turn means that it implicitly induces an instance variable declaration which is similar to the formal parameter declaration (the details are described in the feature specification).

// Using a primary constructor.
class A(var int a, final int b);

// Same thing, using current Dart.
class A {
  int a;
  final int b;
  A(this.a, this.b);
}

It used to be possible to mark formal parameters (in general, not just the ones in constructors) as final. This used to mean that the formal parameter itself was immutable. However, we decided that this feature should no longer be supported, which means that it will be an error to put final on a formal parameter of any function other than a declaring constructor. This ensures that var/final on a formal parameter unambiguously indicates that it is declaring.

This decision was somewhat controversial (we had looooong discussions about how to specify that a parameter is declaring or non-declaring), but we ended up saying that "has var or final <=> is declaring" because we consider it to be very important that the syntax unambiguously shows whether or not a given parameter is declaring. This does give rise to some inconveniences for developers who prefer to use immutable formal parameters (they're forced to change their code to not do that any more). However, final formal parameters are not common today, and it's not hard to teach dart fix to remove final in the locations where it is an error to have it.

Also note that it is arguably an implementation detail whether or not the body of a function can assign a new value to a parameter, which means that it shouldn't actually be part of the syntactic signature of the function in the first place.

A similar issue occurs because var name can no longer be a formal parameter declaration unless it occurs as a formal parameter of a declaring constructor (and it is then a declaring parameter). Luckily that's exceedingly rare, anyway.

[RohitSaily]

thanks for the breakdown, that makes sense. i forgot about non-declaring formal parameters

i am on-board with the current design but just for the sake of exploration, i noticed an initializer list directly in the class header is not part of the design and instead the declaring body constructor or this: /*initializer list*/ is used. would an initializer list in the header not be feasible or be considered syntactically noisy? eg

class A(Node node, int depth): _secretMember=(node, depth)
{ final (Node, int) _secretMember;
}