More capable `Type` objects

[eernstg]

This issue is a response to #356 and other issues requesting virtual static methods or the ability to create a new instance based on a type variable, and similar features.

Static substitutability is hard

The main difficulty with existing proposals in this area is that the set of static members and constructors declared by any given class/mixin/enum/extension type declaration has no interface and no subtype relationships:

class A {
  A();
  A.named(): this();
  static int foo => 1;
  static int bar => 2;
}

class B extends A {
  B();
  static int foo => -1;
  static int baz => -3;
}

As a fundamental OO fact, B is an enhanced version of A when it comes to instance members (even in this case where we don't enhance anything), but it is simply completely unrelated when it comes to constructors and static members.

In particular, the relationship between the constructors A(); and B(); is very different from an override relationship. A has a constructor named A.named but B doesn't have a constructor named B.named. The static member B.foo does not override A.foo. B does not inherit A.bar. In general, none of the mechanisms and constraints that allow subtype substitutability when it comes to instance members are available when it comes to "class members" (that is, static members and constructors).

Consequently, it would be a massively breaking change to introduce a rule that requires subtype substitutability with respect to class members (apart from the fact that we would need to come up with a precise definition of what that means). This means that it is a highly non-trivial effort to introduce the concept which has been known as a 'static interface' in #356.

This comment mentions the approach which has been taken in C#. This issue suggests going in a different direction that seems like a better match for Dart. The main difference is that the C# approach introduces an actual static interface (static members in an interface that must be implemented by the class that claims to be an implementation of that interface). The approach proposed here transforms the static members into instance members, which means that we immediately have the entire language and all the normal subsumption mechanisms, we don't have to build an entirely new machine for static members.

What's the benefit?

It has been proposed many times, going back to 2013 at least, that an instance of Type that reifies a class C should be able to do a number of things that C can do. E.g., if we can do C() in order to obtain a new instance of the class C then we should also be able to do MyType() to obtain such an instance when we have var MyType = C;. Similarly for T() when T is a type variable whose value is C.

Another set of requests in this topic area is that static members should be virtual. This is trivially true with this proposal because we're using instance members of the reified Type objects to manage the access to the static members.

There are several different use cases. A major one is serialization/deserialization where we may frequently need to create instances of a class which is not statically known, and we may wish to call a "virtual static method".

Proposal

We introduce a new kind of type declaration header clause, static implements, which is used to indicate that the given declaration must satisfy some subtype-like constraints on the set of static members and constructors.

The operand(s) of this clause are regular class/mixin/mixin-class declarations, and the subtype constraints are based on the instance members of these operands. In other words, they are supertypes (of "something"!) in a completely standard way (and the novelty arises because of that "something").

The core idea is that this "something" is a computed set of instance members, amounting to a correct override of each of the instance members of the combined interface of the static implements types.

abstract class A<X> {
  int get foo;
  void bar();
  X call(int _);
  X named(int _, int _);
}

class B static implements A<B> {
  final int i;

  B(this.i);
  B.named(int i, int j): this(i + j);
  
  static int get foo => 1;
  static void bar() {}
}

These declarations have no compile-time errors. The static analysis notes the static implements clause, computes the corresponding meta-member for each static member and for each constructor, and checks that the resulting set of meta-members amount to a correct and complete set of instance members for a class that implements A<B>. Here is the set of meta-members (note that they are implicitly created by the tools, not written by a person):

mixin MetaMembers_Of_B on Type implements A<B> {
  B call(int i) => B(i);
  B named(int i, int j) => B.named(i, j);
  int get foo => B.foo;
  void bar() => B.bar();
}

The constructor named B becomes an instance method named call that takes the same arguments and returns a B. Similarly, the constructor named B.named becomes an instance method named named. Static members become instance members, with the same name and the same signature.

The point is that we can now change the result of type Type which is returned by evaluating B such that it includes this mixin.

This implies that for each constructor and static member of B, we can call a corresponding instance member of its Type:

void main() {
  dynamic t = B; // `t` is the `Type` that reifies `B`.
  t(10); // Similar to `B(10)`, yields a fresh `B`.
  t.named(20, 30); // Ditto, for `B.named(20, 30)`.
  t.foo; // Similar to `B.foo`.
  t.bar(); // Similar to `B.bar()`.
}

This shows that the given Type object has the required instance members, and we can use them to get the same effect as that of calling constructors and static members of B.

We used the type dynamic above because those methods are not members of the interface of Type. However, we could change the typing of type literal expressions such that are not just Type. They could be Type & M in every situation where it is known that the reified type has a given mixin M. We would then be able to use the following typed approach:

class C static implements A<C> {
  final int i, j;

  C(int i): this(i, i);
  C.named(this.i, this.j): assert(i < j);
  
  static int get foo => 1000;
  static void bar() {}
}

void main() {
  var t = B; // `T` has type `Type & MetaMembers_Of_B`.

  // With that in place, all of these are now statically checked.
  t(10); t.named(20, 30); t.foo; t.bar();

  // We can also use the type `A` in order to abstract the concrete class away.
  X f<X>(A<X> a) {
    a.bar();
    return switch (a.foo) {
      1 => a(),
      _ => a.named(),
    };
  }

  B b = f(B);
  C c = f(C);
}

Next, we could treat members invoked on type variables specially, such that T.baz() means (T).baz(). This turns T into an instance of Type, which means that we have access to all the meta members of the type. This is a plausible treatment because type variables don't have static members (not even if and when we get static extensions), so T.baz() is definitely an error today.

We would need to consider exactly how to characterize a type variable as having a reified representation that has a certain interface. Let us use the following, based on the syntax of regular type parameter bounds:

X f<X static extends A<X>>() { // New relationship that `B` and `C` satisfy.
  X.bar();
  return switch (X.foo) {
    1 => X(),
    _ => X.named(),
  };
}

void main() {
  B b = f(); // Inferred as `f<B>();`.
  C c = f(); // Inferred as `f<C>();`.
}

Even if it turns out to be hard to handle type variables so smoothly, we could of course test it at run time:

X g<X>() { // No specialized bound.
  var Xreified = X;
  if (Xreified is! A<X>) throw "Ouch!";
  Xreified.bar();
  return switch (Xreified.foo) {
    1 => Xreified(),
    _ => Xreified.named(),
  };
}

void main() {
  B b = f(); // Inferred as `f<B>();`.
  C c = f(); // Inferred as `f<C>();`.
}

Customized behavior

The behavior of the reified type objects can be customized, that is, they can do other things than just forwarding a call to a static member or a constructor.

One possible approach could be to have static extends C with M1 .. Mk in addition to static implements T1 .. Tn on type introducing declarations (like classes and mixins), and then generate the code for the reified type object such that it becomes a subclass that extends C with M1 .. Mk and also implements T1 .. Tn. However, we could also apply those mixins outside the static extends clause, so we only consider a simpler mechanism:

A type introducing declaration can include a static extends C clause. This implies that the reified type object will be generated such that the given C is the superclass. Compile-time errors occur according to this treatment. E.g., if C is a sealed class from a different library then static extends C is an error, based on the fact that it would give rise to a subclass relation to that class, which is an error.

This mechanism allows the reified type object to have arbitrary behaviors which can be written as code in the class which is being used as the static extends operand.

Use case: An existential open mechanism

One particular kind of feature which could be very useful is a flexible mechanism that delivers the behaviors otherwise obtained by an existential open mechanism. In other words, a mechanism that allows the actual type arguments of a given class to be accessed as types.

This would not involve changes to the type system (so it's a much smaller feature than a real existential open would be). It is less strictly checked at compile time, but it will do the job—and it will presumably be used sparingly, in just that crucial bit of code that allows a given API to be more convenient to use, and the API itself would be statically typed just like any other part of the system.

For example, the reified type object could implement this interface:

abstract class CallWithTypeParameters {
  int get numberOfTypeParameters;
  R callWithTypeParameter<R>(int index, R Function<T>() callback);
}

A class C with a single type parameter X could use static extends _CallWithOneTypeParameter<X>, which would make it implement CallWithTypeParameters:

abstract class _CallWithOneTypeParameter<E> implements CallWithTypeParameters {
  int get numberOfTypeParameters => 1;
  R callWithTypeParameter<R>(int index, R Function<Y>() callback) {
    if (index != 1) {
      throw ArgumentError("Index 1 expected, got $index");
    }
    return callback<E>();
  }
}

For example, assume that the standard collection classes will use this (note that this is a non-breaking change):

abstract mixin class Iterable<E> static extends _CallWithOneTypeParameter<E> {
  ... 
}

abstract interface class List<E> static extends _CallWithOneTypeParameter<E>
    implements Iterable<E>, ... {
  ...
}
...

The 'existential open' feature is so general that it would make sense to expect system provided classes to support it. It also makes sense for this feature to be associated with a very general interface like CallWithTypeParameters, such that all the locations in code where this kind of feature is needed can rely on a well-known and widely available interface.

If we have this feature then we can deconstruct a type of the form List<T>, Set<T>, ..., and use the actual type argument:

X build<X, Y>(Y y) {
  if (<X>[] is List<List>) {
    // `X` is `List<Z>` for some `Z`.
    final reifiedX = X as CallWithTypeParameters;
    return reifiedX.callWithTypeParameter(1, <Z>() {
      return <Z>[build<Z, Y>(y)];
    }) as X;
  } else if (<X>[] is List<Set>) {
    // `X` is `Set<Z>` for some `Z`.
    final reifiedX = X as CallWithTypeParameters;
    return reifiedX.callWithTypeParameter(1, <Z>() {
      return <Z>{build<Z, Y>(y)};
    }) as X;    
  } else if (<Y>[] is List<X>) {
    // `Y <: X`, so we can return `y`.
    return y as X;
  } else {
    throw ArgumentError("Inconsistent call `build<$X, $Y>(_)");
  }
}

void main() {
  String v1 = build('Hello!'); // Passthrough, 'Hello!'.
  List<num> v2 = build(1); // `<num>[1]`.
  Set<List<int>> v3 = build(2); // `<List<int>>{<int>[2]}`.
  print('v1: ${v1.runtimeType} = "$v1"');
  print('v2: ${v2.runtimeType} = $v2');
  print('v3: ${v3.runtimeType} = $v3');
}

Obviously, this involves some delicate low-level coding, and it needs to be done carefully. However, the resulting API may be considerably more convenient than the alternatives.

In particular, an API could use regular objects that "represent" the composite types and their type arguments. Those type representations would then be handled by an interpreter inside build. For example, with this kind of approach it is probably not possible to obtain a helpful return type, and it is certainly not possible to use type inference to obtain an object that "represents" a type like Set<List<int>>.

Running code, emulating the example above.

abstract class CallWithTypeParameters {
  int get numberOfTypeParameters;
  R callWithTypeParameter<R>(int index, R Function<T>() callback);
}

abstract class _CallWithOneTypeParameter<E> implements CallWithTypeParameters {
  int get numberOfTypeParameters => 1;
  R callWithTypeParameter<R>(int index, R Function<Y>() callback) {
    if (index != 1) {
      throw ArgumentError("Index 1 expected, got $index");
    }
    return callback<E>();
  }
}

// Assume `static extends _CallWithOneTypeParameter<E>` in collection types.

class ReifiedTypeForList<E> extends _CallWithOneTypeParameter<E> {}
class ReifiedTypeForSet<E> extends _CallWithOneTypeParameter<E> {}

// Workaround: Allow the following types to be used as an expression.
typedef _ListNum = List<num>;
typedef _ListInt = List<int>;
typedef _SetListInt = Set<List<int>>;

CallWithTypeParameters? emulateFeature<X>() {
  return switch (X) {
    const (_ListNum) => ReifiedTypeForList<num>(),
    const (_ListInt) => ReifiedTypeForList<int>(),
    const (_SetListInt) => ReifiedTypeForSet<List<int>>(),
    _ => null,
  };
}

X build<X, Y>(Y y) {
  if (<X>[] is List<List>) {
    // `X` is `List<Z>` for some `Z`.
    final reifiedX = emulateFeature<X>() as CallWithTypeParameters;
    return reifiedX.callWithTypeParameter(1, <Z>() {
      return <Z>[build<Z, Y>(y)];
    }) as X;
  } else if (<X>[] is List<Set>) {
    // `X` is `Set<Z>` for some `Z`.
    final reifiedX = emulateFeature<X>() as CallWithTypeParameters;
    return reifiedX.callWithTypeParameter(1, <Z>() {
      return <Z>{build<Z, Y>(y)};
    }) as X;    
  } else if (<Y>[] is List<X>) {
    // `Y <: X`, so we can return `y`.
    return y as X;
  } else {
    throw ArgumentError("Inconsistent call `build<$X, $Y>(_)");
  }
}

void main() {
  String v1 = build('Hello!'); // Passthrough, 'Hello!'.
  List<num> v2 = build(1); // `<num>[1]`.
  Set<List<int>> v3 = build(2); // `<List<int>>{<int>[2]}`.
  print('v1: ${v1.runtimeType} = "$v1"');
  print('v2: ${v2.runtimeType} = $v2');
  print('v3: ${v3.runtimeType} = $v3');
}

Type parameter management

With this mechanism, a number of classes will be implicitly induced (that is, the compiler will generate them), and they will be used to create the reified type object which is obtained by evaluating the corresponding type as an expression.

The generated class will always have exactly the same type parameter declarations as the target class: If class C has 3 type parameters with specific bounds then the generated class will have the same type parameter declarations with the same bounds. This implies that T in static implements T or static extends T is well defined.

abstract class A<Y> {
  void foo();
  List<Y> get aList => <Y>[];
}

class C<X1 extends B1, X2 extends B2> static extends A<X2> {
  static void foo() => print('C.foo running!');
}

// Implicitly generated class.
class ReifiedTypeForC<X1 extends B1, X2 extends B2> extends A<X2> {
  void foo() => C.foo();
  // Inherited: `List<X2> get aList => <X2>[];`
}

// Example, where `String` and `int` are assumed to satisfy the bounds.
void main() {
  void f<X static extends A>() {
    X.foo(); // Prints 'C.foo running!'.
    print(X.aList.runtimeType); // 'List<int>'.
  }
  
  f<C<String, int>>();
}

More capable type objects as an extension

We may well wish to equip an existing type that we aren't able to edit (say, String) with reified type object support for a particular class.

We can do this by adding a "magic" static member on the class Type as follows:

class Type {
  ...
  static DesiredType? reify<TypeToReify, DesiredType>() {...}
}

This is, at first, just a less convenient way to reify a type (passed as the type argument TypeToReify) into a reified type object. With an actual type argument of Type (or any supertype thereof), the returned object is simply going to be the reified type object that you would also get by simply evaluating the given TypeToReify as an expression.

However, if DesiredType is not a supertype of Type then the reified type object may or may not satisfy the type constraint (that is, it may or may not be an instance of a subtype of DesiredType). If it is not an instance of the specified DesiredType then reify will attempt to use an extension of the reified type of TypeToReify.

Such extensions can be declared in an extension declaration. For example:

extension E<X> on List<X> {
  static extends _CallWithOneTypeParameter<X>;
}

At the location where Type.reify<List<int>, CallWithTypeParameters>() is invoked, we gather all extensions in scope (declared in the same library, or imported from some other library), whose on-type can be instantiated to be the given TypeToReify. In an example where the given TypeToReify is List<int>, we're matching it with List<X>.

For this matching process, the first step is to search the superinterface graph of the TypeToReify to find the class which is the on-type of the extension. In the example there is no need to go to a superinterface, the TypeToReify and the on-type of the extension are already both of the form List<_>.

Next, the value of the actual type arguments in the chosen superinterface of the TypeToReify is bound to the corresponding type parameter of the extension. With List<int> matched to List<X>, X is bound to int.

Next, it is checked whether there is a static implements T or static extends T clause in the extension such that the result of substituting the actual type arguments for the type parameters in T is a subtype of DesiredType.

In the example where TypeToReify is List<int> and DesiredType is CallWithTypeParameters, we find the substituted static implements type to be _CallWithOneTypeParameter<int>, which is indeed a subtype of CallWithTypeParameters.

If more than one extension provides a candidate for the result, a compile-time error occurs.

Otherwise, the given reified type object is returned. In the example, this will be an instance of the implicitly generated class for this static implements clause:

class ExtensionE_ReifiedTypeForList<X> extends _CallWithOneTypeParameter<X>
    implements Type {}

The result is that we can write static implements and static extends clauses in extensions, and as long as we're using the long-form reification Type.reify<MyTypeVariable, CallWithTypeParameters>(), we can obtain an "alternative reified object" which is specifically tailored to handle the task that CallWithTypeParameters was designed for.

If we're asking for some other type then we might get it from the reified type object of the class itself, or perhaps from some other extension.

Finally, if the reified type object of the class/mixin/etc. itself doesn't have the DesiredType, and no extensions will provide one, then Type.reify returns null.

It is going to be slightly less convenient to use Type.reify than it is to simply evaluate the type literal as an expression, but the added expressive power will probably imply that Type.reify will be used for all the more complex cases.

Revisions

• Feb 21, 2025: Added a section about extension-like reified type objects. Added a section about how to manage type parameters in the implicitly induced class that defines the reified type object.
• Feb 20, 2025: Further developed the ideas about customized behavior.
• Feb 14, 2025: Add the section about customized behavior.
• Dec 10, 2024: Adjust the mixin to be on Type.
• Dec 9, 2024: First version.

[lrhn]

The approach proposed here transforms the static members into instance members,

That sounds like a Kotlin companion object.
I don't claim to understand Kotlin, but my understanding is that Kotlin doesn't have static members as such, only instance members on companion objects, which can be called just like static members otherwise would. The difference is that you can add interfaces to the companion object (otherwise each companion object is a singleton class instance with no relations to other classes) and that you can access the companion object as an object, and pass it around.

static implements

Can we have static extends to inherit static members? static with to add mixins?
(Or should we go the companion object way and require you to use an embedded declaration if you want more control,
like:

class C {
  // Before any static member:
  static class extends A.class with HelperMixin1 implements HelperType2;
  // Following static members are membes of this static class.
}     

and you can access the type as C.class, or C.static. Or something.

You can only extend or implement a Name.class type in another static companion class, to ensure that they all extend the real Type.

The constructor named B becomes an instance method named call

We probably still want to ensure that tear-offs from a static-member type is a canonicalized constant. Somehow. (That's one of the reasons I don't want normal classes to be able to implement the special singleton classes.)

To make this equivalent to the current behavior, I assume constructors have access to the type parameters of the
type object, so var l = List<num>; var vs = l.filled(24, 42); will be the same as var vs = List<num>.filled(24, 42);.
The other static members have no access to type variables.
And we want List<int>.copyRange and List<String>.copyRange (let's assume there is a static helper function with that name on List) to be identical, even if they are torn off from different instances. So some care is needed for that.

(Also, it's currently possible to have class C { C(); static void call() {} }, so just converting every static member to an instance member, and unnamed constructor to a call method, can be a conflict. One of them have to surrende.
Alternatively we can allow new as a member name that can only be declared indirectly using a constructor, but that still means you can't write (C)() and invoke the constructor. Or the call method. The ambiguity is still there.)

Type & M

Rather than needing this intersection, just let the generated mixin be on Type and have it actually extend the real Type type.
All such types implement Type, and their own companion interface MyName.class.

X static extends A

Probably want both a non-static and static type bound, say X extends Widget static extends Jsonable.
Having to throw away one of the types to use the other is going to be a problem.

---

This will be yet another reason to allow static and instance members with the same name.
I'd like to declare the toString of my static member objects, or have it be comparable, while the class itself is also comparable.
It'll happen. If not with this, then with static extensions, or any other feature that makes statics more important.

How will this interact with runtimeType?
Will A().runtimeType return the static Type object. (Yes, what else?)
Will the return type of runtimeType default to A.class when it's not overridden? (No, it's a virtual getter, so subclasses must override correctly, and there is no default type relation between the static member object's types.)

So, runtimeType stays useless, but if anyone does:

dynamic x;
// ...
 ...  (Object? o) { 
    ...
    x = o.runtimeType;   
    ...
...
x.foo();

we may have to retain a lot of static methods that could be tree-shaken today, because we can't tell statically whether they're invoked or not.
That's one advantage with static declarations today: they're either visibly used, or they're dead code.
When we turn static declarations into instance members, and allow casting the instance to Object and then dynamic, they're no longer static methods, and resolution is only going to be an approximation.

print((int).runtimeType); // _Type
print((int).runtimeType.runtimeType); // _Type
print((String).runtimeType); // _Type

But... if int and String, as type objects, have the same type (_Type), they should have the same methods. But, according to my reading of the proposal, (int).parse("0") will be valid, but (String).parse("0") won't. 😕

(I think, the explanation is that (String).runtimeType is _Type, but String.runtimeType is not defined - but this difference is just an artifact of syntax. Will "Hello".runtimeType.runtimeType be different from ("Hello".runtimeType).runtimeType? Probably not. Not sure what to make of this 😄)

Maybe a function like static(String) can solve the problem? It will return something like _Static$String, which will be a regular object that can be a part of expression like static(MyClass) is MyInterface, static(MyClass) as MyInterface etc.

[lrhn]

I would say that int.runtimType returns the same value as the expression int, but with static type Type.
The runtime type would be the type denoted by, fx, int.class, which is a subtype of Type.

Then int.runtimeType.runtimeType has the runtime type int.class.class.
We may want to limit the recursion here. Maybe say that the second-level runtime type is always the same type, plain Type, since the second level runtime types have no members at all. Any static member object with no members is a Type with no extra mixin, and since you can't declare a static static member, only the first level of .class can be proper subtypes of Type.

Or maybe that's a bad idea, because of what it does to tree shaking.
Maybe it's better to let runtimeType return a plain Type object representing the type, without the extra members from the static declarations.
It must still be equal to the object with the static members, but may not have the same runtimeType.

That is:

• (strawman syntax) if A denotes a type declaration, then A.class denotes the static and runtime type of the expression A or A<T1,…,T2>.
• If A declares no static members, and either has no constructors or the declaration is abstract, then A.class is the type Type
• If A does declare a static member, or a constructor and is not abstract, then A.class denotes an implicit, unnamed subclass of Type which has the static members as instance members. That class has no static members or constructors. It may or may not be allowed to declare static operators, maybe including operator==
• The object returned by Object.runtimeType is a plain Type object, with no extra instance members. If A.class does not override Type.==, then A().runtimeType == A, even of the latter has more members.

A generic type's class objects have instances for each instantiation, and the constructor members can access those.
The object for List<int>.class differs from List<String>.class as of they were different instantiations of a generic class (same generic mixin applied to Type, but different instantiation, so different runtime types, and constructor methods have different return types.)

The getters and setters of static variables are not represented by instance variables, they all access the same global variable's state.

[eernstg]

Great comments and questions, @lrhn!

That sounds like a Kotlin companion object.

It's similar to Kotlin (and Scala) companion objects, but also different in other ways:

I'm not suggesting that Dart classes should stop having the static members and constructors that we know today, I'm just proposing that we should allow developers to request access to some of the static members and constructors (determined by the interface of the T in static implements T) using the reified types that we already have.

This differs from the companion objects in that there is no support for obtaining a companion object from a given actual type argument (because the type argument was erased). In contrast, a Dart type argument will always be able to deliver the corresponding Type object (just evaluate the corresponding type parameter as an expression). We may then invoke the (forwarding methods to the) static members and constructors of the underlying type, if this access has been provided.

For example:

abstract class A<X> { X call(); }

class B1 static implements A<B1> {}
class B2 {}

void main() {
  var type = someExpression ? B1 : B2;
  if (type is A) {
    var newObject = type();
  }
}

This means that the Kotlin/Scala developer must predict the need to invoke static members or constructors up front (when the concrete type is known) and must pass a reference to the required companion object(s) along with the base data. In contrast, Dart programs can pass type arguments along in the same way they do today, and then it will be possible to get access to the static members and constructors arbitrarily late, as long as the given type is available as the value of a type parameter.

In the case where a class does not have a static implements clause, the reified Type will be exactly the same as today, it's only the classes that are explicitly requesting this feature which will have a somewhat more expensive reified type.

Can we have static extends to inherit static members? static with to add mixins?

This seems to imply that we would implicitly generate a static member or a constructor from the instance method implementations. This may or may not be doable, but I'm not quite sure what the desired semantics should be.

When it comes to code reuse I would prefer to have good support for forwarding, possibly including some abstraction mechanisms (such that we could introduce sets of forwarding methods rather than specifying them one by one). This could then be used to populate the actual class with actual static members as needed, such that it is able to have the desired static implements clause.

We probably still want to ensure that tear-offs from a static-member type is a canonicalized constant

I think the current approach to constants based on constructors and static members is working quite well. The ability to access static members and constructors indirectly via a reified type is an inherently dynamic feature, and I don't think it's useful to try to shoehorn it into a shape where it can yield constant expressions. There's no point in abstracting over something that you already know at compile time anyway.

Rather than needing this intersection, just let the generated mixin be on Type and have it actually extend the real Type type.

Good point! Done.

Will A().runtimeType return the static Type object. (Yes, what else?)

I'm not quite sure what A means here. In my examples A is an abstract class which is used as the operand of static implements (that is, it's the "static interface" that the class B and C declare the required static members to "statically implement"), but it might just as well have been a concrete class (B and C don't care).

In that case, A().runtimeType would evaluate to the reified instance of Type (or a subtype) that represents the class A. It may or may not have some instance forwarders to static/constructor members of A, just like any other reified type. The whole thing is "getting rather meta" really quickly if A is used in static implements clauses of other classes, and also has its own static implements clause, but I don't see why it wouldn't work.

That's one advantage with static declarations today: they're either visibly used, or they're dead code.

A class that doesn't have a static implements clause doesn't have any new ways to invoke its static members or constructors, so they can be tree-shaken just as well as today.

A class that does have a static implements clause makes some of its static members and constructors callable from the implicitly generated forwarding instance members, but this is no worse than the following:

class A {
  static int get foo => 1;
}

class B {
  void foo() {
    print(A.foo);
  }
}

We may still be able to detect that B.foo is never invoked, and no other call sites for B.foo exist, so B.foo can be tree-shaken out of the program.

With "more capable Type objects" we need to track one more thing: Does it ever happen that a reified type object for a given class/mixin/etc. is created? If this may happen then we may obtain an object which is capable of calling a static method (via a forwarding instance member of that reified type object).

It may be harder, but it does sound like a task whose complexity is similar to that of tracking invocations of instance members. That is, if we're able to determine that B.foo above is definitely not called, couldn't we also determine that it is never going to be the case that a reified type object for a given class is created?

[eernstg]

@tatumizer wrote:

But... if int and String, as type objects, have the same type (_Type), they should have the same methods. But, according to my reading of the proposal, (int).parse("0") will be valid, but (String).parse("0") won't. 😕

If you evaluate a type literal (such as int or String, but let's just use an example where we can decide whether or not there is a static implements clause on the class), the result will have static type Type. The run-time type is not specified currently, but the actual implementations may use a specific private _Type, or whatever they want. Nobody has a lower bound on this run-time type, just like it is with almost any other run-time type.

In particular, it is certainly possible for an implementation to evaluate B and obtain a reified type whose run-time type is of the form MetaMembers_Of_B (which is a subtype of Type and a subtype of A<B>, in the example).

Those reified objects may then have different interfaces, that is, they support invocations of different sets of members, so certainly it's possible for (int).parse("0") to be (1) statically type correct, and (2) supported by the expected implementation (which is the static method int.parse) at run time.

On the other hand, the reified String type does not have a parse instance method, because there is no parse static method in String to forward to (and hence it would be a compile-time error for String to have a static implements Something where Something has a String parse(); member). So (String).parse("0") is a compile-time error, and (String as dynamic).parse("0") throws at run time.

There's nothing special about this (and that's basically the point: I want this mechanism to use all the well-known OO mechanisms to provide flexible/abstract access to the static members and constructors which are otherwise oddly inflexible, from an OO perspective).

Maybe a function like static(String) can solve the problem? It will return something like _Static$String, which will be a regular object that can be a part of expression like static(MyClass) is MyInterface, static(MyClass) as MyInterface etc.

If we have B and C with a static implements A<...> clause then B evaluated as an expression is a regular object. It is also a reified type, but that doesn't prevent that it can be a perfectly normal object with normal semantics and applicability.

So we can certainly do B is MyInterface in order to detect whether the class B has MyInterface as a static interface. We would presumably evaluate the type literal and get a Type object and store it in a local variable in order to be able to promote the reified type such that we can use this fact:

abstract interface class MyInterface {
  int get foo;
}

class D static implements MyInterface {
  static int get foo => 1;
}

void f<X extends D>() {
  var reifiedX = X;
  if (reifiedX is MyInterface) {
    print(reifiedX.foo);
  }
}

[Wdestroier]

Could the following code similar to C#'s syntax:

abstract class Json {
  static fromJson(Map<String, dynamic> json);
  Map<String, dynamic> toJson();
}

class User implements Json { ... }

be syntatic sugar for this proposal's syntax?

abstract class Json$1 {
  Map<String, dynamic> toJson();
}

abstract class Json$2 {
  fromJson(Map<String, dynamic> json);
}

class User implements Json$1 static implements Json$2 { ... }

To keep static implements as an internal Dart abstraction / implementation detail, but I may be missing edge cases.

EDIT:
I chatted with mateusfccp and he commented "This would be the same as just making static part of the interface, which would basically break the entire universe". To avoid this problem, the base class must have the static method without a body (or marked as abstract). Another point was "you wouldn't be able to provide a default implementation, or else it would become a regular static method". If a static method with an implementation has to be abstract (probably rare), then it could have an abstract modifier imo.

I can't imagine any piece of code implementing the same interface for instance methods and static methods. However, I can imagine most use cases implementing an interface with instance methods and static methods. That's why I would prefer if instance and static interfaces were merged.

@eernstg wrote:

So we can certainly do B is MyInterface in order to detect whether the class B has MyInterface as a static interface

This can't be! Today String is Object is tautologically true, but under the proposed reforms, the predicate will acquire a new meaning: "String implements static interface of Object", which is not true: static interface of Object includes the method hash and a couple of others, but these methods are not inherited by String. No, we need a different hierarchy and a different syntax for the "companions". Maybe String.class will do, not sure.
The way it's defined above is difficult to wrap my head around. 😄

(An argument against String.class syntax is that we will now have the notions of type and class, which might be very confusiing. We need a syntax for "get static interface of type B", so I think static(B) or B.static would be more appropriate)

[lrhn]

String is Object is tautologically true because the expression String evaluates to a Type object, and Type is a subtype of Object.

The Type object that Foo of class Foo static implements Bar evaluates to is an object that implements Type and Bar. It will certainly have a toString and hashCode implementation because it's an object (and an Object).

That doesn't mean that Foo has a static toString, but it does absolutely mean that (Foo).toString() will be allowed, the "static interface implementation object" (or whatever we'll call it) that the expression Foo evaluates to does implement Object, and Type, and in this case also Bar.

(I chose String.class as strawman syntax because it's for accessing "class members", but also mainly because static is not a reserved word, so Foo.static might mean something. It better not, but it could.
You can do some weird stuff with classes and extensions if you really want to.
Like the expression static(C).static(C.static.static.C).static(C).static.)

Spoiler:

void main() {
  static(C).static(C.static.static.C).static(C).static;
}

class C {
  static C get static => C();
  C call(Object? value) => this;
}

C static(Type value) => C();

typedef _C = C;
extension on _C {
  _C get static => this;
  _C get C => this;
}

Just to clarify: speaking of Object methods, I didn't mean hashCode or toString. I meant static methods of Object, which are:
hash, hashAll and hashAllUnordered. But I see your point: class String.static certainly implements Object, but it doesn't implement Object.static. To implement Object.static, class A has to say class A static implements Object, right?

static is not a reserved word, so Foo.static might mean something

That's not the reason to disqualify the word - in practice, it won't hurt anyone. Most people believe static is a keyword anyway. And if used in the form static(A), you can be quite certain no one has a global method called static. (It might be even possible to reserve the keyword static retroactively).

Still, it's not clear what static(A).runtimeType or static(static(A)) will evaluate to. Some synthetic types like _Static$A and _Static respectively?

[lrhn]

Class A It would have to say class A static implements Object.static, which would give it nothing (as I now understand @eernstg's proposal) because Object won't have any static implements clause, so Object.static is just Type.

If A is a regular class, we can always say class B implements A, and implement all methods of A in B.
Similarly, I guess the class can say class B static implements A.static and implement static methods of A in B (or else the compiler will complain about unimplemented methods).
So, if we declare class B static implements Object.static we will have to implement no-arg constructor, hash, hashAll and hashAllUnordered.
or else the compiler will complain. (Just a guess)

Q: Can class say class B /* no "static"! */ implements A.static? And what will it even mean? (Probably not, b/c "this" type mistmatch).

Kotlin's companion object model is worth looking into, it won't take long: https://kotlinlang.org/docs/object-declarations.html#companion-objects

Main difference is that the companion object has a name and a type, and - most importantly - Kotlin has a word for it, which is (predictably) "companion object". It would be very difficult to even talk about this concept without the word, so I will use it below.

The idea is that you can extract a companion object from the object, e.g., (using dart's syntax), FooCompanion companion = foo.Companion (the name is by default capitalized, but you can assign any name). This immediately brings the companion object to a familiar territory, thus radically simplifying understanding.

I don't know if there's a simple way to express the same concept in dart without introducing the term "companion object". Does anyone have issues with this wording?

Interestingly, you very rarely need to extract the companion object explicitly, but the very possibility of doing so explains a lot: it's a real object; consequently, it has a type; this type can extend or implement other types - the whole mental model revolves around the term "companion object".

[eernstg]

@Wdestroier wrote:

Could the following ... be syntactic sugar for this proposal's syntax:

abstract class Json {
  static fromJson(Map<String, dynamic> json);
  Map<String, dynamic> toJson();
}

class User implements Json { ... }

Desugared:

abstract class Json$1 {
  Map<String, dynamic> toJson();
}

abstract class Json$2 {
  fromJson(Map<String, dynamic> json);
}

class User implements Json$1 static implements Json$2 { ... }

I agree with @mateusfccp that it is going to break the world if a clause like implements Json implies not just the instance member constraints that we have today, but also a similar set of constraints on the static members (and, we should remember, constructors!).

In other words, it's crucial for this proposal that static implements has no effect on the subtypes of the declaration that has this clause, each class starts from scratch with respect to the static interface.

abstract class StaticInterface1 { int get foo; }
abstract class StaticInterface2 { void bar(); }

class B static implements StaticInterface1 {
  final int i;
  B(this.i);
  static int get foo => 10;
}

class C extends B static implements StaticInterface2 {
  C(super.i);
  static void bar() {}
}

This also implies that there is no reason to assume that a type variable X has a specific static interface just because we know that X is a subtype of Y, and Y has that static interface.

void f<X extends Y, Y static extends StaticInterface1>() {
  Y.foo; // OK.
  X.foo; // Compile-time error, no such member.
}