Support exhaustive pattern match on a generic type argument

[Zekfad]

Currently there are no good way to perform an exhaustive check for a type arguments of a generic function.
There are two methods with drawbacks:

• ex. f1: Perform direct Type comparison - not exhaustive and error prove if hierarchy changes, no hints if type is unrelated:
• ex. f2: Perform exhaustive check on some generic object - requires allocation of new runtime object (likely bad for performance).

I believe there should be a better mechanism for this, such as special syntax which will perform match without allocating generic container or some internal symbol which will serve as synthetic container instead of List in example.

I think this will help with performance, dead code elimination and reduce developer induced errors.

sealed class A {}
final class B extends A {}
final class C implements A {}

String f1<T extends A>() => switch(T) {
    const (B) => 'B',
    const (C) => 'C',
    const (A) => throw StateError('Unbound type T of A.'),
    // no hint for unrelated type
    const (int) => throw StateError('Impossible state.'),
    // not exhaustive
    _ => throw StateError('Impossible state.'),
};

// Requires dynamic object allocation and check for unrelated "List"
String f2<T extends A>() => switch(<T>[]) {
    List<B>() => 'B',
    List<C>() => 'C',
    List<A>() => throw StateError('Unbound type T of A.'),
};

void main() {
  print(f1<C>());
  print(f2<C>());
}

[mateusfccp]

T is a Type. A Type value can be, well, any Type.

f2 is the current best approach, and it works. I'm pretty sure this extra allocation will be irrelevant for 99.99% of the cases.

[Zekfad]

Indeed it works, but I believe there's a room for improvement.

[mateusfccp]

Yeah, that's the point of your issue. Just explaining what is happening here, and simply trying to work with f1 syntax wouldn't work.

I'm not sure if a specific syntax for this would work, but there are other issues to improve comparison between types that could work with switches.

See, for instance, #2090, #3837.

[lrhn]

There are three issues here.

Converting to Type object throws away information. That's never the solution to anything, because Type objects are generally useless.

The only type that exhaust T extends S by subtype checks is S, so being exhaustive shouldn't be a goal.

None of these checks actually promote T, because type variable promotion is not currently a thing in Dart.
Even if you recognize that the type of one of B or C, the type system won't know that that type is a subtype of T, so if you try to use the type asking with T, you'll end up with casts.

The best way to think of type parameters, and generics, is that they should be generic, and treat all the possible types the same, in a generic way. If you try to figure out which type a type parameter is actually bound to, and have different code paths, the code is no longer generic, and as you can see, that's not really something generics is designed for.

Here you should just have two functions, one for B and one for C, then the caller has to figure out which one to call.

[Zekfad]

Thanks for the feedback!

Could you please help me with what are the more ideomatic solutions for these two problems:

As far as I understand in Flutter composition is preferred over inheritance, therefore having two identical widgets that differs in let's say 1-2 method calls is suboptimal from maintenance perspective, switch on type feels like a more natural approach there (minimizing maintenance cost and reducing copy-paste).

When we want to convert/map constrained generic argument (from external package) to some other parameter, for example converting generic calls into API calls, we have to switch over type, because we can't modify external package and use polymorphism (also it would tightly couple the code).

Real world example, we have trait interface Likable and API like method; like button widget has generic that accepts T of Likable and shows count, calls the API client generic method. We do type switch in a client to choose which ID filed to populate. We're not promoting the type, since interface already has everything we need, we only need to map Type.
Another case is when we have to gaze into generic to select the correct localization string.

[lrhn]

favor composition over inheritance

That means that your class should not implement an unrelated interface, like anList or Stream, just because the class has something that behaves in that way. It should expose a Stream of its events, or a List of its elements, not be one.

Having two subclasses of an abstract superclass which only differ in the implementation of one method is ... precisely what object oriented programming was designed for.

Trying to make the class generic, and then switching on the type parameter (no matter how) is bad generic design. And it doesnt work the way people usually think because the type parameter can also be bound to the shared supertype or to Never.

So make it

sealed class WBase<T extends A> {
   // The things that always work the same 
   ... Concrete members
   // The things that need to be specialized
   String get elementText;
}
class WB extends WBase<B> {
  String get elementText => "To B or not to B";
}
class WC extends WBase<C> {
  String get elementText => "I like C";
}

Maximal reuse, class based specialization, actually generic generics.

That does not work with an API that isn't written for it, but if you need to interface with a generic API, your code needs to either follow that API's generics, or wrap it in a different abstraction.

Peeking into the generic type is a code smell, usually a square-peg-round-hole issue.
Pragmatically, if you can make it work, then it works, but it's breaking an abstraction somewhere, or is trying to handle things at different level than where the needed information is known.

With generics, you know the instantiation at the surface of the generic API. You don't need to look at the type there, if you are instantiating with a real type. If you try to move operations that depend on that type into the generic code, you get this issue.

(And sometimes it's just a problem because you're trying to do something that really is reflection, without having reflection. Try not to do that, it's going to hurt eventually.)