Specify treatment of missing type arguments in redirecting factory constructors

[eernstg]

Currently we do not specify explicitly how to deal with the case where a redirecting factory constructor omits actual type arguments from the redirectee:

class A<S extends num, T extends num> {
  // Redirectee accepts 3 type arguments, `S` and `T` are in scope, no relation expected.
  factory A("argumentList") = B;
}

class B<X extends num, Y extends num, Z extends num> implements A<X, Y> {
  B("argumentList") {
    print("Constructing a B<$X, $Y, $Z>");
  }
}

void main() {
  // Inference applies to `B` when invoked explicitly, will select 3 type arguments
  // to `B` such that the resulting instance has a suitable type for assignment to `x`.
  A<int, int> x = new B("actuals");
  // This case is similar, but not currently specified.
  new A<int, int>("actuals");
}

This issue is intended to ensure that the specification treats the above class A in the same way as the following variant:

class A<S extends num, T extends num> {
  factory A("argumentList") { return new B("arguments"); }
}

for which we already have a well-established inference process. Note that this approach was discussed in #30855 first, this issue just exists in order to focus on the specification task which is not the main topic of that issue.

This may be added to dartLangSpec.tex when we specify instantiate-to-bound in general, or it may be added in some feature spec before that (but we don't currently have any feature specs where it fits naturally).

[eernstg]

No milestone now: This will not block Dart 2.

[eernstg]

Note that we already have the following in dartLangSpec.tex on redirecting factory constructors (where $k$ is the redirecting factory constructor and $k'$ is its redirectee):

Calling a redirecting factory constructor $k$ causes the constructor
$k'$ denoted by $type$ (respectively, $type.identifier$) to be called with
the actual arguments passed to $k$, and returns the result of $k'$ as the result of $k$.
The resulting constructor call is governed by the same rules as an instance creation
expression using \NEW{} (\ref{instanceCreation}).

This implies that the static checks applied to the invocation of the redirecting factory constructor $k$ correspond to the static checks that would be applied to the corresponding invocation of the redirectee $k'$, and missing type arguments for $k$ are treated like missing type arguments for $k'$, etc.

This makes it a natural generalization (when the language specification is updated to cover inference) that inference of type arguments for $k$ should amount to inference on the corresponding invocation of $k'$, which is exactly what this issue requests.

So the current language specification already says what it should say in order to "generalize naturally" to do what this issue requests. Hence, this issue exists simply as a reminder to double-check that the update to include inference does indeed satisfy this expectation.

[eernstg]

Marking this issue as blocked, awaiting specification of inference (global: #27499, local: #27500).

[eernstg]

Note the following example: #32988 (comment). It shows how the current treatment allows for a heap invariant violation (c refers to an instance of C<dynamic>, but it has type annotation C<int>), but it also shows that the type arguments in the redirection of the constructor C.infer falls back on dynamic (instantiate to bound?) and never checks that the type of the returned object is appropriate.

So that's a case where the situation addressed in this issue plays a major role: If that type argument had been chosen by inference then the code could have been in good shape (using C<T1>), otherwise it may be an error that the type argument is omitted at all, or we might choose instantiate-to-bound and then raise an error because C<dynamic> won't work.

[lrhn]

I think we should specify that we perform inference on the redirectee, if necessary. In almost all cases, it will be a simple copying over of the type arguments. In a few cases, there will be more complicated situations, but no more complicated than if we had just written => Redirectee(arguments) instead of = Redirectee.

If we do not infer, then it must be a compile-time error if a constructor does not guarantee that the created object is a subtype of the constructed class's type.

[eernstg]

If we do not infer, then it must be a compile-time error if a constructor does
not guarantee that the created object is a subtype of the constructed class's type.

With 9282a34 that is indeed a compile-time error (and the spec currently always assumes that inference has already taken place).

[eernstg]

Closing: We've decided that we will add a specification of inference (of any kind) in a later edition of the language specification, and until then the specification will express everything under the assumption that inference has taken place already. This means that this issue can be closed: Inference for this case will be specified elsewhere (than dartLangSpec.tex), and if there is no result from inference then we will use instantiate to bound, which is handled in instantiate-to-bound.md, which is being integrated into the language specification in a separate effort.