Generic Type Inheritance Checking

[Peng-Qian]

Problem

It seems generic type inheritance checking is not easy in Dart.
Solution one will have a long checking code when subtypes amount increased.
Solution two had more creation cost at the runtime.

Is it possible to provide a handy way of checking generic type inheritance?
Such as new keyword(maybe?):

T inherits Parent

Functions and Type Inheritance

void main() {
  checkType<Child>();
}

class Parent {}

class Child extends Parent {}

void checkType<T extends Parent>() {
   ...
}

[==] check

  print('[==] check can only check the exact type: ');
  if (T == Parent) {
    print('Tpye == Parent');
  } else {
    print('Tpye != Parent');
  }

  if (T == Child) {
    print('Tpye == Child');
  } else {
    print('Tpye != Child');
  }

[is] check

  print('\n[is] check fail any tpye check: ');
  if (T is Parent) {
    print('Type is Parent');
  } else {
    print('Type is not Parent');
  }

  if (T is Child) {
    print('Type is Child');
  } else {
    print('Type is not Child');
  }

[switch] check

  print('\n[switch] can only check the exact type: ');
  switch (T) {
    case Parent:
      print('Type match case Parent');
      break;
    default:
      print('Type is not matched case Parent');
  }

  switch (T) {
    case Child:
      print('Type match case Child');
      break;
    default:
      print('Type is not matched case Child');
  }

Solution one

  if (T == Parent || T == Child) {
    print('Type is either Parent or Child');
  } else {
    print('Type is neither Parent nor Child');
  }

Solution two

  if (<T>[] is List<Parent>) {
    print('Type is either Parent or Child');
  } else {
    print('Type is neither Parent nor Child');
  }

Results

[==] check can only check the exact type: 
Tpye != Parent
Tpye == Child

[is] check fails any type check: 
Type is not Parent
Type is not Child

[switch] can only check the exact type: 
Type is not matching case Parent
Type match case Child

solution one: 
Type is either Parent or Child

solution two: 
Type is either Parent or Child

[lrhn]

If you have a type variable <T extends Parent> and want to check whether the type bound to T is a subtype of Child, then you can't do it directly. There are not affordances for comparing type variables directly to other types, only for checking instances against the type.

There is a simple workaround, though, using a helper class or function.

The simplest approach is:

bool isSubtype<S, T>() => <S>[] is List<T>;

Then you can ask isSubtype<T, Child>() and get a true when T represents a subtype of Child, and a false when T is Parent.

A more generalized helper class could be:

class TypeHelper<T> {
  const TypeHelper();
  bool operator >=(TypeHelper other) => other is TypeHelper<T>;
  bool operator <=(TypeHelper other) => other >= this;
  bool operator >(TypeHelper other) => this >= other && !(other >= this);
  bool operator <(TypeHelper other) => other >= this && ! (this >= other);
}

Then you could do:

var tType = TypeHelper<T>();
if (tType <= const TypeHelper<Child>()) ... 

(In general, don't use Type objects for anything, they're not good solutions to anything except using dart:mirrors).

[lrhn]

I'll take the emojis as a sign we've answered the question. 🎉

[Peng-Qian]

Yes! Many thx!@lrhn

[Wheat2018]

nice!🎉

[escamoteur]

I got bitten by that just today again because I thought is was possible to just use is for that.
Why isn't it possible to compare types directly with is? doesn't the compiler now enough about types?

[eernstg]

I think it's helpful to think about this kind of question in terms of a metaphor:

It's a bit like having a picture of an elephant and asking "does this picture weigh more than one ton?". That's probably never going to be true, and it seems likely that you really wanted to ask "does the elephant which is depicted by this picture weigh more than one ton?", which might very well be true. However, we can't really know the answer to this improved question if we only have the picture, except if we happen to know that every grown elephant weighs more than one ton, and we can see that the elephant isn't very young.

So int is num is (almost certainly) a wrong question because it puts a type in the position where the is operator expects to receive an object (so we're providing a "picture" where the real thing is expected). Yes, we can obtain an object (of type Type) if we use a type as an expression (just like we can weigh a picture), but it's very unlikely that int is num was written with the intention to test whether or not that object has the type num, because that's just a verbose way to write false.

The issue is like a type (or kind) error, plus a coercion: The is operator's left operand must be an object, and we`re passing a type (which can be coerced into an object when used as such, but in this particular case we probably don't want that).

We could have a dynamic subtype operator (let's use the syntax <: for that operator, as in int <: num). This operator would have the syntax <type> '<:' <type> rather than <bitwiseOrExpression> 'is' <type>, and it would evaluate to true if and only if the left operand denotes a subtype of the right operand.

It is probably not a good idea to try to combine these two operators into one (that is, making is work like the current is in some cases and like <: in other cases, based on static or run-time information):

There is a syntactic mismatch (so we can't write all kinds of types on the left hand side of is), and there's a semantic ambiguity: If we encounter o is T where o has the static type Object (or any other type which is a proper supertype of Type) then it could be a Type object, in which case we might want to test whether o is a subtype of T, but it might also be a regular (non-Type) object where we'd want to test whether o is an instance of T.

So we do need a workaround for those (relatively rare?) cases where we want to test a subtype relationship dynamically, but we do have a standard way to express that: <S>[] is List<T> yields true if and only if S is a subtype of T.

I created this lint proposal to flag these usages of is: #59428.

[escamoteur]

But is the test if a generic type parameter is a subtype of some other type really a dynamic runtime check? Couldn't that be checked at compile time already? Am 22. März 2024, 12:14 +0100 schrieb Erik Ernst ***@***.***>:

…

I think it's helpful to think about this kind of question in terms of a metaphor: It's a bit like having a picture of an elephant and asking "does this picture weigh more than one ton?". That's probably never going to be true, and it seems likely that you really wanted to ask "does the elephant which is depicted by this picture weigh more than one ton?", which might very well be true. However, we can't really know the answer to this improved question if we only have the picture, except if we happen to know that every grown elephant weighs more than one ton, and we can see that the elephant isn't very young. So int is num is (almost certainly) a wrong question because it puts a type in the position where the is operator expects to receive an object (so we're providing a "picture" where the real thing is expected). Yes, we can obtain an object (of type Type) if we use a type as an expression (just like we can weigh a picture), but it's very unlikely that int is num was written with the intention to test whether or not that object has the type num, because that's just a verbose way to write false. The issue is like a type (or kind) error, plus a coercion: The is operator's left operand must be an object, and we`re passing a type (which can be coerced into an object when used as such, but in this particular case we probably don't want that). We could have a dynamic subtype operator (let's use the syntax <: for that operator, as in int <: num). This operator would have the syntax <type> '<:' <type> rather than <bitwiseOrExpression> 'is' <type>, and it would evaluate to true if and only if the left operand denotes a subtype of the right operand. It is probably not a good idea to try to combine these two operators into one (that is, making is work like the current is in some cases and like <: in other cases, based on static or run-time information): There is a syntactic mismatch (so we can't write all kinds of types on the left hand side of is), and there's a semantic ambiguity: If we encounter o is T where o has the static type Object (or any other type which is a proper supertype of Type) then it could be a Type object, in which case we might want to test whether o is a subtype of T, but it might also be a regular (non-Type) object where we'd want to test whether o is an instance of T. So we do need a workaround for those (relatively rare?) cases where we want to test a subtype relationship dynamically, but we do have a standard way to express that: <S>[] is List<T> yields true if and only if S is a subtype of T. I created this lint proposal to flag these usages of is: dart-lang/sdk#59428. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[eernstg]

How would you resolve this one at compile time?

import 'dart:math';

void f<X, Y>() {
  print(<X>[] is List<Y> ? 'Yes!' : 'No.');
}

void main() {
  if (Random().nextBool()) f<int, num>(); else f<num, int>();
}

[escamoteur]

ok, I guess I don't fully understand how generics are handled during compiling I still have the old C++ in mind.
Not sure that it would be really a problem to have an is operator that can be used on objects and types as the usage above feels very intuitive to do so and I'm not sure how it could be applied wrongly. However having a <: operator for that that could also deal with Type objects as well as with generic type parameters would be pretty handy.
I don't think that this is such a rare case especially if you develop libraries and want to check if the passed parameters are what they should be. Not always is it possible to limit the possible generic types to a certain subtype but hat to be checked when the function is called.

[busslina]

Was implemented that hypothetical <: operator?
If not, my proposal is to create an operator implements or isSubtype