Let a wildcard as an actual type argument indicate a request for inference

[eernstg]

This is a proposal for supporting expressions like MyClass<int, _>('Hello'), where _ is used to indicate that the corresponding type parameter should be obtained from type inference. This allows us to specify some type arguments whose value would otherwise not fit the needs, and omit other type arguments whose inferred value is as desired. For example:

class A<X, Y> {
  final X x;
  final _ys = <Y>[];
  A(x);
  void add(X Function(Y) g) => _ys.add(g(x));
}

// Assume that we want to create an `A<int, String>`.
void main() {
  // We can specify all type arguments, ..
  var a1 = A<int, String>(42); // .. but `int` is redundant.

  // We can infer all type arguments, ..
  var a2 = A(42); // .. but `Y` is now `dynamic`.

  // With this proposal, we get the best of two worlds.
  var a3 = A<_, String>(42);
}

We could allow a wildcard type argument that occurs as the last element of the actual type argument list to stand for multiple type arguments. For example, this would allow us to use C<T1, _> to stand for C<T1, T2, T3> where both T2 and T3 are inferred.

There should not be a large amount of expressive power in this feature, but it does take a few steps to emulate it in the current language.

We can get the same effect today if we're willing to create a type alias for each choice of fixed type arguments, and if those type arguments can be denoted globally:

// Same `class A`.

typedef AHelper<X> = A<X, String>;

void main() {
  // Emulate `A<_, String>(42)`.
  var a4 = AHelper(42); // Creates an `A<int, String>` and infers that type for `a4`.
}

We can also use a function to support arbitrary choices of "fixed" type arguments:

// Same `class A`.

// Create a context where we can denote a type which isn't denotable globally.
void foo<Z>() {
  // Emulate `A<_, Z>(42)`.
  // Note that we can't declare `typedef AHelper<X> = A<X, Z>;`
  // because type aliases are global.

  // We can still specify all type arguments, brute force.
  var a5 = A<int, Z>(42);

  // However, we want to avoid specifying `int` because it can be inferred. So we
  // use a local function that has the choice of `Z` as 2nd type argument baked in.
  A<V, Z> local<V>(V v) => A(v);
  var a6 = local(42);
}

void main() => foo<String>();

It is a new feature to include a special (wildcard-ish) treatment of _ when it is used as an actual type argument. It is also (slightly) breaking because it is possible today to declare some entities whose name is _ (e.g., top-level variables or, indeed, type parameters).

However, I think it's more helpful to allow developers to request this kind of partial type inference by means of _ than it is to preserve the ability to use a type whose name is _ as an actual type argument.

In the end, it would actually be possible to create a type alias to provide access to such types under a different name:

class _ {}
typedef AMuchBetterName = _;
List<AMuchBetterName> list = []; // Can't use `List<_>`, but this is better, anyway.

[rrousselGit]

Consider a more complex example:

class A<T> {}

class B<FirstT extends A<SecondT>, SecondT> {}

If we write:

B<A<int>, _>

Would this infer B<A<int>, int>?

[eernstg]

Current type inference would not generate any constraints on SecondT, so it ends up being a top type. Here's a variant of the example that shows the outcome:

class A<X> {
  A(X x);
}

class B<Y extends A<Z>, Z> {
  B(Y a) {
    print('B<$Y, $Z>');
  }
}

void main() {
  B(A(42)); // 'B<A<int>, dynamic>'.
}

This is a valid result from type inference because binding Z to a top type is actually a choice that allows us to satisfy all the subtype constraints.

However, we're currently working on an improvement of the type inference algorithm (see #3009) that gives rise to additional constraints. This will allow us to infer a tighter solution, namely B<A<int>, int>.

So the proposal in this issue would allow us to ask for inference, and we'd then rely on other enhancements (of type inference itself) in order to get the more tight result.

PS: Yes, #3009 is about F-bounded type parameters, but the solution that we're currently evaluating is more general than F-bounds, and in particular it does allow us to bind Z to int in this example.

[RohitSaily]

Definitely would benefit from this! Generic code that tracks a lot of type parameters throughout is a bit noisy because of the need to constantly specify parameters that are otherwise "obvious" or deducible assuming strictest inference

I think being able to omit parameters to be inferred entirely would be preferable, like how it is done for optional positional method parameters. With types what is inferred is accepted as the default, so an optional-by-default approach fits quite naturally

void main()=>
	function<Descendant>(); // Trailing AncestorT is omitted, so it is inferred

void function<AnyAncestor extends Ancestor<AncestorT>, AncestorT>()
	{}
class Ancestor<T>
	{}
class Descendant extends Ancestor<num>
	{}

Just a little more compact for trailing cases

[eernstg]

I can see a few different levels of explicitness:

1. In use today: We can pass zero or all actual type arguments for any instantiation of a generic entity (e.g., calling a generic function like f(42) vs. f<int, String>(42), specifying a type annotation like Map vs. Map<int, String>).
2. Initial proposal here: Like (1), but we can use _ as one or more actual type arguments to indicate that the corresponding type parameter should be computed using type inference (like f<_, String>(42) or Map<int, _>).
3. Slight relaxation of (2): We can use _ as an actual type argument, like (2), and we can use _ as the last actual type argument to represent any positive number of actual type arguments (like bool b = g<int, _>(42, true); meaning bool b = g<int, String, bool>(42);)
4. It is always allowed to pass a smaller number of actual type arguments than the number of type parameters, and the omitted ones will be computed by type inference (like bool b = g<int>(42) with the same meaning as in (3)).
5. (4) as well as (2): _ can be used for non-last actual type arguments, and the last type argument(s) can be omitted entirely.

The type annotation case may be particularly interesting because type annotations currently use instantiation to bound rather than type inference (so List xs = [1]; makes xs a List<dynamic>, not a List<int>, but List<_> xs = [1]; would infer the declared type as List<int> based on the initializing expression).

Similarly, ys is List<_> where ys has type Iterable<num> would be inferred to mean ys is List<num> (to compare: ys is List can be used today, and it means ys is List<dynamic>, which won't promote ys because List<dynamic> is not a subtype of Iterable<num>).

I think I'd go for an approach where it is made explicit that some type arguments have been omitted, for example, approach (3) above.

It is probably too error prone to allow the last type arguments to be omitted without syntactic hints about the omission. For example, developers might forget some of the type arguments, or forget to add more type arguments if the declaration of the generic entity is updated. On the other hand, you could say that we're already allowing an even more error prone notation when all actual type arguments have been omitted. A reader of the code may see g(42) and assume that g is a plain non-generic function, and it might still be the case that the inferred type arguments are different from the ones that are required for correctness according to the design of the surrounding software. On the third hand ;-), it could be claimed that it's a good thing that we can change a declaration to add one or more new type parameters, and call sites where some type arguments are passed will just use the inferred value for those new type arguments (which means that it is a much less breaking change to add a new type parameter to an existing declaration).

[alex-medinsh]

I think I'd go for an approach where it is made explicit that some type arguments have been omitted, for example, approach (3) above.

developers might forget some of the type arguments, or forget to add more type arguments if the declaration of the generic entity is updated

I'd say that allowing _ to mean "any number of type arguments" is not far from just allowing omitting the arguments altogether. Developers can still forget any type argument after the second one. If a new argument is added later, they could still forget to add it.

I think it either has to be "use _ for every param that needs to be inferred" or just allow omitting any number of params. 3 adds new syntax while suffering from the same issues as just omitting the params without any new syntax. I vote 4 :)

[eernstg]

I think it either has to be "use _ for every param that needs to be inferred" ..

I think I'd be more happy about that one, I'm a little bit worried about having hard-to-see bugs caused by actual type arguments being omitted by mistake.

[RohitSaily]

I think the complete omission of trailing parameters is useful because in generic-heavy code there may be a lot of desired inferring but then it would be littered with _ (in addition to its other uses, such as leading library-private identifiers). To me the whole point of the inference is to keep the syntax minimal because the type is easily inferable, usually once the reader has even a little bit of contextual understanding of the code

I would make both (explicit trailing _ and omission of trailing parameters) syntactically valid and introduce a lint rule that enforces _ usage for those who want that explicitness. If the explicitness is considered more in line with standard Dart styling (which I don't think it is given how things work "out-of-the-box") it can be made a standard lint or on by default, and then explicitly turned off