Add infer keyword

[AlexanderFarkas]

Let:

abstract class Entity<T> {
  T get id;
}

class EntityStore<T extends Entity<K>, K> {
  T getById(K id) {
    ...
  }
}

class Customer extends Entity<int> {
  final int id;
  Customer(this.id);
}

Calling Code:
final store = EntityStore<Customer, int>();

But type parameter K could already be inferred from T:
final store = EntityStore<Customer>(); // this doesn't work

I propose infer keyword for type parameters that could be inferred from other type parameters:
class EntityStore<T extends Entity<K>, infer K> {}

[lrhn]

Should type bounds really be type patterns?

class EntityStore<T extends Entity<var K>> { ... }

@munificent

[eernstg]

We've had similar discussions previously, e.g., #620 (comment).

[munificent]

That's a really interesting idea. What about in parameter lists?

foo(List<final T> someList) { ... }

Deciding when to use a generic method and when to use a type pattern seems like a tricky and subtle design choice.

[leafpetersen]

What about in parameter lists?

My initial take would be to avoid this, and instead add the first class version of extractTypeArguments that we've discussed. I think the latter provides a strict super set of this functionality?

[lrhn]

The distinction between foo<T>(List<T> someList) { ... } and foo(List<final T> someList) { ... } would be that the latter destructures the actual runtime type of the argument and extracts type arguments. The former takes a separate type as argument, which the list's element type must be a subtype of.

The pattern-in-parameter is no different from doing foo(List<dynamic> someList) { if (someList is List<final T>) { ... }}, and can possible even be desugared to that.

There is no way to separate the List<final T> type from the actual runtime type, which is also why there is no type parameter for the function.

The next question would be whether you can do add(List<final T> list, T value) { list.add(value); }. You probably cannot. That's dependent typing and you can't statically ensure its safety, so it can't be allowed in a binding pattern which relies on static type soundness. (Same likely applies to doing type matching inside record matching, the type can't be used again in the same match if it's a binding match.) It's probably possible to use it in a matching pattern, because then it can fail to match.

We probably can allow the return type to depend on the pattern-matched type variable, like T mid(List<final T> list) => list[list.length ~/ 2];, because the return statements happen inside the scope of the binding.

It might very well be that some generic methods would be better written as pattern-matching type-extractors.
I can't remember one right now, though. (A lot of generic methods are only generic in order to allow an existential type, like void apply<A>(void Function(A) f, A arg) => f(arg);. Those still need the type parameter, because the type affects both parameters.)

So, a pattern like List<final T extends num> would both constrain the type that it can match and extract the runtime element type if it matches.

[munificent]

What about in parameter lists?

My initial take would be to avoid this, and instead add the first class version of extractTypeArguments that we've discussed. I think the latter provides a strict super set of this functionality?

Yeah, the patterns proposal already covers this use case. But thinking about using type patterns in bounds made me wonder about using them in other places where type parameters can occur when binding is happening and parameter lists are another example of that. (This, of course, also raises the question of allowing other kinds of patterns in parameter lists.)

The pattern-in-parameter is no different from doing foo(List<dynamic> someList) { if (someList is List<final T>) { ... }}, and can possible even be desugared to that.

Yeah, I think this is the right approach. Allowing type patterns directly in the parameter list seems like a can of worms.

[lrhn]

The pattern-in-parameter is no different from doing foo(List<dynamic> someList) { if (someList is List<final T>) { ... }}, and can possible even be desugared to that.

Yeah, I think this is the right approach. Allowing type patterns directly in the parameter list seems like a can of worms.

I was actually using that as an argument for allowing patterns in parameter lists. Pattern-parameters are statically typed irrefutable binding constructs, just like what variable declarations become with patterns, so I don't think there should be any problem, and forcing people to declare the un-patterned variable and then immediately pattern-match it inside the function, is just adding overhead.

[pedromassango]

I think we should close this in favor of #620 as they address the exact same issue but with different proposed solutions. Or the other way around.

[pedromassango]

btw, is this ticket (or #620) something that is being considered/talked about by the team? 👀

[TimWhiting]

Cross referencing with the issue related to patterns #2221

[shtse8]

In my use case, I want to wrap a list in generic type with a class without knowing what inner type is.

T wrap(T obj) {   
  if (obj is List) obj = ReactiveList(obj) as T
  return obj;
}

where ReactiveList<T> extends List<T>.

Resulting in:

_CastError (type 'ReactiveList<dynamic>' is not a subtype of type 'List<int>' in type cast.

Is it possible to infer the type?

T wrap(T obj) {   
  if (obj is List<var V>) obj = ReactiveList<V>(obj) as T
  return obj;
}

[AlexanderFarkas]

@shtse8 Why not just

ReactiveList<T> wrap<T>(Iterable<T> list) {
  return ReactiveList(list);
}

[shtse8]

@shtse8 Why not just

ReactiveList<T> wrap<T>(Iterable<T> list) {
  return ReactiveList(list);
}

because T is probably other types, not only list.
wrap is one of the methods in class. the value stored in the class is generic type but I just need to wrap it if the type is List.

class Ref<T> {
  T value;
  Ref(T value) : this.value = _wrap(value);

  T _wrap(T obj) {   
    if (obj is List) obj = ReactiveList(obj) as T
    if (obj is Map) obj = ReactiveMap(obj) as T
    return obj;
  }
}