Revisit unimplemented factory constructors and default values

[eernstg]

We need to introduce an extra rule about factory constructors that are subject to augmentation: They can omit default values.

With augmentations, a factory constructor can be unimplemented. It is possible to make a late choice about the nature of this constructor (it could be redirecting or it could be non-redirecting):

class A {
  A();
  factory A.foo(); // Unimplemented factory constructor.
}

augment class A {
  augment factory A.foo() = A;
}

class B {
  B();
  factory B.foo(); // Unimplemented factory constructor.
}

augment class B {
  augment factory B.foo() {
    return B();
  }
}

We may need to introduce an extra rule about these unimplemented factory constructors which says that it is allowed for an optional parameter to omit the default value clause, even in the case where the parameter type is potentially non-nullable.

For example:

class A {
  A([int i = 0]);
  factory A.foo([int i]); // Currently an error; this issue proposes to allow it.
}

augment class A {
  augment factory A.foo([int i]) = A; // Default value obtained from redirectee.
}

The general rules about augmentations state that no default value can be specified by an augmentation, it must always be specified by the introductory declaration (if there is to be a default value for that parameter at all).

This implies that the declaration above would not allow A.foo to be augmented with a class body (such that it is a non-redirecting factory constructor): The parameter type cannot be modified by an augmentation, and an augmentation cannot provide a default value. In other words, the fact that there is no default value has eliminated the expressive power to make the decision about the factory being redirecting or non-redirecting, it's always forced to be redirecting.

We could allow the unimplemented factory constructor to include the default value and then ignore it (because it would be an error to have it) when the constructor is augmented to be redirecting:

class A {
  A([int i = 0]);
  factory A.foo([int i = 1]); // Currently allowed.
}

augment class A {
  augment factory A.foo([int i]) = A; // Currently an error; this issue suggests we might allow it.
}

class B {
  B();
  factory B.foo([int i]); // Proposed: Allow this.
}

augment class B {
  augment factory B.foo([int i = 3]) { // We could allow this.
    return B();
  }
}

If we do not allow this then the choice to have a default value will force the constructor to be non-redirecting.

In other words, the ability to "decide late" whether a given factory is redirecting or not will disappear as soon as there is one or more optional parameters whose type is potentially non-nullable. Of course, we can then make the declarations inconsistent: If we have two such parameters and provide a default value for exactly one of them then no augmenting declarations can be written, because they will give rise to a compile-time error no matter what.

@dart-lang/language-team, WDYT? Are you willing to allow a default value to (1) occur in an augmenting declaration, and/or (2) be declared in the introductory declaration, but then erased in the final definition because tit would be an error?

[jakemac53]

My opinion is to not change anything here other than possibly augmenting the definition of "potentially redirecting" to indicate that the presence (or absence) of a default value on an optional, non-nullable parameter will determine the type of the constructor (as in redirecting or not).

It isn't intended to be a feature that an augmentation can alter this property of the constructor, this "potentially redirecting" definition is only there to describe how we handle the case where we can't know from the introductory declaration, not to try and add flexibility.

Edit: If we don't allow providing the default value but no body today, we should allow that.

[lrhn]

I do want to introduce flexibility.

If a user writes a constructor signature, and adds a macro to it, I do want to give the macro the flexibility to choose the implementation.

That said, any number of details can lock the declaration onto being redirecting or not:

• const implies factory (for now, I have an issue asking for const non-redirecting factory constructors.)
• a default value implies non-redirecting.
• a redirection or body is obvious.

It really is just the plain signature that is ambiguous.

[eernstg]

One approach we could use would be to say that the default value can be specified in an otherwise pluripotent (sounds better than 'ambiguous' ;-) constructor declaration, and if it is an error to specify that default value in the resulting constructor definition then it will simply be ignored. We might want to maintain that it is an error if there are two conflicting default values in the same augmentation chain, or we could even allow that to enhance the overall flexibility. Example:

class A {
  A([int i = 0]);
  factory A.foo([int i = 1]); // OK.
}

augment class A {
  augment factory A.foo([int i]) = A; // OK, and the "inherited" default value is ignored.
}

class B {
  B([int i = 0]);
  factory B.foo([int i = 1]); // OK.
}

augment class B {
  augment factory B.foo([int i]) { // OK, and the default value is "inherited".
    return B(i);
  }
}

class C {
  C([int i = 0]);
  factory C.foo([int i = 1]); // OK.
}

augment class C {
  augment factory C.foo([int i = 2]) { // Error?
    return C(i);
  }
}

Taking one step back, I think we have the following main players when it comes to constructor augmentation:

graph LR
  subgraph Factory
    direction BT
    fnr["Non-redirecting<br>factory A(int i) => B(i);"] --> fp["Pluripotent<br>factory A(int i);"]
    fr["Redirecting<br>factory A(int i) = B;"] --> fp
  end
  subgraph Generative
    direction BT
    gnr["Non-redirecting<br>A(int i) {...}"] --> gp["Pluripotent<br>A(int i);"]
    gr["Redirecting<br>A(int i) : this(i + 1);"] --> gp
  end

Loading

This is already somewhat inhomogeneous because the pluripotent generative constructor is usable as such, but the pluripotent factory is a new invention (an 'unimplemented' factory), and it is an error unless there is an augmentation which will implement it (by redirection or by a body).

The fact that some of these arrows can be blocked by parameter default values makes the situation one more bit inhomogeneous.

[eernstg]

Perhaps we should go a step further and simply say that it is not a supported feature to change the kind of constructor using augmentation? (It's a mess!)

So we would accept an introductory declaration like A(int i); (generative, non-redirecting, can add a body and/or an initializer list) or a introductory declaration like factory A(int); (factory, non-redirecting, can add a body), but they cannot be augmented into redirecting constructors. In short, the pluripotent forms are now always non-redirecting.

If you wish to declare a redirecting constructor in an augmentation chain then it just needs to be introduced as such. If there is no A(int i); in the augmented declaration then it is not an error to declare A(int i) : this.name(i + 1); in the augmenting declaration. Similarly for the redirecting factory.

I think this implies that there would not be any situations where a default value can be declared in the introductory declaration, and it becomes an error to have it in the augmenting declaration, or vice versa.

This takes away a little bit of expressive power, but it also gives rise to a more consistent (and less confusing) model.

graph LR
  subgraph Factory
    direction BT
    fnr["Non-redirecting<br>factory A(int i) => B(i);"] --> fp["Pluripotent<br>factory A(int i);"]
    fr["Redirecting<br>factory A(int i) = B;"]
  end
  subgraph Generative
    direction BT
    gnr["Non-redirecting<br>A(int i) {...}"] --> gp["Pluripotent<br>A(int i);"]
    gr["Redirecting<br>A(int i) : this(i + 1);"]
  end

Loading

[jakemac53]

Perhaps we should go a step further and simply say that it is not a supported feature to change the kind of constructor using augmentation? (It's a mess!)

We should in general have a principle that we don't allow you to change any which could be introspected on, because that leads to different introspection results in different phases.

And, we probably do need to give you the ability to check if a constructor is redirecting or not, because it informs how you can augment the constructor.

Therefore, I think we are left with really only two reasonable options:

• Seal the type of constructor based on its introductory declaration.
• Expose the "pluripotent" property of constructors which could be redirecting or generative. This would have to be updated in between macros and would introduce unfortunate ordering constraints and reduced parallelism.

[lrhn]

Expose the "pluripotent" property of constructors which could be redirecting or generative.

Could be .isNonRedirecting and .isRedirecting that both return false.

(Redirecting and generative are not mutually exclusive. We have almost all eight combinations of const or not, factory or generative, and redirecting and non-redirecting.)

Perhaps we should go a step further and simply say that it is not a supported feature to change the kind of constructor using augmentation? (It's a mess!)

Then it's not possible to augment a redirecting generative constructor, because it can only be redirecting if it has written a redirection, and we don't allow changing that redirection.
It's not possible to write a plain signature and allow someone else to decide the implementation, and let them choose whether that implementation is redirecting or not.

I would like that flexibility, to be able to write a signature and let a macro worry about the implementation, without my signature being taken as an implementation in itself.

Maybe allow abstract C(); as a pluripotent generative constructor, so you have something to write (and later augmentations can then add an implementation, removing the abstract. They have to, a constructor must not be abstract in the end.)

[munificent]

Now that augmentations don't need to support every possible thing a macro could want to do, I think we have the opportunity to simplify a bit here. Here's a proposal:

• A constructor like A(); or A() { ... } always declares a generative non-redirecting constructor. An augmentation can provide or add a body, but can't change it to be factory or redirecting.

• A constructor like factory A(); or factory A() { ...} always declares a factory non-redirecting constructor. Again, an augmentation can provide or add a body, but can't change it to be generative or redirecting.

• Redirecting constructors (generative or factory) can only be created by the initial declaration of a constructor. (The initial declaration may be inside a class augmentation, but it can't be a constructor augmentation.)

• Redirecting constructors can't be augmented.

In short:

• As usual, an augmentation can't change any user-visible attribute of a declaration. Once a constructor is generative/const/factory/whatever, it must stay that way.

• Redirecting constructors and augmentations don't mix.

We could allow mixing them in a future language version if really compelling. But, honestly, I would much rather go in the direction of enhanced constructors (#4246), potentially const statements (#4261), and function forwarding (#3444). I think there's a path there that would lead us to not needing redirecting constructors at all. Simplifying constructors would be really nice.

What do you think?

[lrhn]

I really think we should allow an "API declaration" that declares what the API properties of a member, including a constructor, should be, and let something else define the implementation.

Whether a constructor is const or not, or is factory or not, are API properties.
Whether it's redirecting is an implementation choice which is invisible in the API.

So I want to be able to write

@GenerateIt()
class A {
  A(int id);
  factory A.byName(String name);
}

and not lock a code generator into A and A.byName being non-redirecting.

I'd rather have the opportunity to allow the generator to decide the implementation strategy, and risk errors,
than just not having an option at all. It won't be an error then, unless the generator comes back and says "I won't run unless you make the constructor redirecting first". In that case, you win nothing other than having to write more text.

I prefer the variant of of augmentation where you can only add implementation once (like #4203) because it avoids a lot of ordering issues, and the entire augmented thing.
Then it's not an issue if one augmentation turns A() into a redirecting constructor and another tries to add a body, because it's just an error to try to add implementation twice.

We can also allow multiple augmentations that modify implementation, they just have to agree. If they don't, it's a compile-time error, and you should stop having two code generators modify the same thing if they can't agree.

If you end up with

class A {
  const A(int id);
  A copyWith({int? id});
}
// @<generated id="GenerateIt" v="1.1.5" t="20250213111902" h="0x25af397bc9">
class A {
  final int _id;
  final String _trace;
  const A(int id) : this._(id, "A.id($id)");
  A._(this._id, this._trace);
  A copyWith({int? id}) => A._(id ?? this._id, "$trace.copy(${id ?? ""})");
  String toString() => _trace;
}
// @</generated>
// @<generated id="other" ... >
class A {
  final int id;
  const A(this.id);
  int get hashCode => id.hashCode ^ 14f37;
  bool operator ==(Object other) => other is A && id == other.id;
}
// @</generated>

then we have a problem. There are two implementations of const A(int id), and they don't agree, not even on whether it's redirecting or not.
Neither uses augmented (but you shouldn't need to).

In this case we can layer these on top of each other and have a reasonable result:

• First const A(this.id) runs to initialize id, then rather than calling super, it invokes const A(int id) : this._(id, "...");
• That runs and redirects to A._(..).
• Which runs and initializes _id and _trace and calls Object().
• When this comes back it continues A._() (if it hadn't been const and had a body).
• Then returns to the redirecting A(...) : this._(...)
• Then returns to const A(this.id) (if it had had a body).
• And it's done.

It's not necessarily an issue to have a non-redirecting generative constructor on top of a redirecting (it works if your super-cosntructor is redirecting too, it just takes more steps to get to the actual initializing constructor.)

It would be an issue if the generated parts were swapped, though, because a redirecting generative constructor
will not run the constructor it augments.
But that reduces the error-case to having two fragments that declare the same generative constructor, ordered such that a redirecting implementation augments a non-redirecting implementation.

Which really means that augmenting (generative) redirecting constructors is fine. We can do that easily.
It's augmenting with redirecting constructors that can be a problem, because it doesn't have a flow into the augmenting constructor.

Maybe(!) we can allow one redirecting constuctor too, if we think of it more like a super-constructor-invocation.
Your augmenting generative constructor fragments can include at most one super-constructor-invocation or
redirection. No matter where in the stack that super/redirection occurs, it's carried to the top and performed
after all the non-redirecting constructor initialization has happened. Then it jumps to the redirecting constructor
and continues, or to the super-constructor, and when it comes back from there, it runs the bodies as normal.
Probably too high risk of running initialization for the same fragment more than once.
(I tried this, it has issues. So does having redirection constructors only work on constructors in this or prior fragments.)

It's not easy. It might not be possible, but I really do want to try before saying that you can't augment or augment with redirecting constructors. (But I can see that they don't play well with augmentation, because they jump out of the augmentation chain.)

[munificent]

I went ahead and scraped a pub corpus to see how common various kinds of constructors are:

-- Constructor (233346 total) --
 107272 ( 45.971%): generative                    ==============
  56758 ( 24.324%): factory                       ========
  51648 ( 22.134%): const generative              =======
  12332 (  5.285%): factory redirecting           ==
   3894 (  1.669%): const factory redirecting     =
   1222 (  0.524%): generative redirecting        =
    220 (  0.094%): const generative redirecting  =

From skimming the results, it looks like the majority (but not all) of factory redirecting and const factory redirecting constructors are coming from freezed generated code. That suggests to me redirecting constructors are useful for code generators and that that augmentations should play nice with them if possible.

The initial issue here isn't about augmenting constructors adding redirection in general (which the proposal supports). It's about how that interacts with default values. Say you've got a introductory constructor with an optional non-nullable parameter. The declaration may be factory or not and may specify a default value or not:

As it currently stands with the proposal:

• Foo([int x]); Generative and no default value: Useless. The augmentation can't add a default value to make the parameter valid, nor can it turn the constructor into a redirecting factory constructor to make its absence valid.

• Foo([int x = 0]); Generative and default value: Fine. The augmentation can add a generative body or a redirection and either works.

• factory Foo([int x]); Factory and no default value: Half-stuck. The augmentation must turn it into a redirecting factory constructor and can't provide a body.

• factory Foo([int x = 0]); Factory and default value: Half-stuck the other way. The augmentation must turn it into a non-directory factory by providing a body and can't turn it into a redirecting factory constructor.

That does not seem particularly flexible or elegant to me.

I propose that we take the notion of "can only complete once" and do something similar for default values: The introductory and augmenting declarations can omit or provide default values, but a given parameter can only receive a default value from one declaration (introductory or augmenting).

An augmenting constructor can choose to fill in a body or a redirection. Once that's all done, we see if the resulting declaration makes sense (i.e. has no default values if it's a redirecting factory, or does have default values otherwise).

Further, we remove the compile-time error that prevents a redirecting factory constructor from providing default values. Yes, if you write them, they will be dropped on the floor, so it lets users do something confusing and meaningless. But it doesn't seem any more confusing and meaningless to me than:

abstract class C {
  foo([int x = 1]);
}

We allow that and the world hasn't ended, so we can probably be a little looser in redirecting factory constructors too.

Some consequences:

• Someone reading the introductory declaration may not be able to tell what the default value of a parameter is. This is equally true today when reading the declaration of a redirecting factory constructor or an abstract instance method. Not great, but not worse.

• Augmentations have maximum flexibility to choose between a body or redirection for both factory and generative constructors, regardless of whether the introductory declaration provides default values or not.

How does that sound?

Thanks for catching this tricky corner case, Erik!

[eernstg]

@munificent wrote:

The introductory and augmenting declarations can omit or provide default values, but a given parameter can only receive a default value from one declaration (introductory or augmenting).

Very nice analysis!

So we'd have the following relaxations:

• An introductory factory constructor declaration with no redirection and no body can omit parameter default values where otherwise required (just like abstract instance methods).
• An augmenting factory constructor with a body can declare parameter default values on optional parameters.

Moreover, the semantic factory constructor which is defined by an introductory factory and zero or more augmenting factory declarations must specify exactly one default value for each parameter which is optional and whose type is potentially non-nullable, and it must specify at most one default value for each parameter which is optional and whose type is nullable.

The tricky case is when a factory constructor has default values in the introductory declaration, and it is turned into a redirecting factory by an augmenting declaration. In this case we could allow it and ignore the default values (because they are not supported with redirecting factories). This is what the rule above implies. Alternatively, we would generalize redirecting factories to support default values that differ from the ones in the redirectee declaration (this implies that the redirecting factory would be a full-fledged function, not a notation which is fully eliminated at compile time; this is already true for the tear-off, anyway; see also #3427).

I don't think there is a need to change the rules for generative constructor declarations, so they can just specify their default values in the introductory declaration, as before, which is also what we do with all other kinds of functions.

We could allow "exactly one default value" to mean "one or more constant expressions whose values are identical" or "exactly one constant expression". I'd prefer the latter, because constant expressions with identical values may be easy to define and handle, but it doesn't generalize nicely to things like "you can specify one or more function bodies as long as they are equivalent" (that would be a canonical example of a Turing tarpit).