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. Perhaps we could use the following:

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 fancy mechanisms.
  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>();`.
}

Revisions

• 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.

[tatumizer]

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.

[tatumizer]

@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;
}

[tatumizer]

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.

[tatumizer]

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).

[tatumizer]

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.
}

[mateusfccp]

I must say I am in love with this proposal.

It solves many "problems" at once (although it may introduce more? let's see how the discussion goes), and it's a very interesting concept.

I agree that it's not as straightforward to understand it, but once you understand, it makes a lot of sense.

I also understand the appeal in having the dynamic and static interfaces bundled together, as @Wdestroier suggests, so if we could come with a non-breaking and viable syntax for doing it (while still providing the base mechanism), I think it would be valuable.

[eernstg]

@tatumizer wrote:

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.

Today String is Object evaluates to true because String evaluates to an instance of type Type when it is used as an expression, and Type is a subtype of Object. There is nothing in this proposal that changes this behavior.

If you want to test whether the reified type object for String implements a given type you can test this using the same unchanged features: String is SomeStaticInterface. This wouldn't be very useful, because you can just use the current syntax to call String.aStaticMethod() if String has that static method, but it would be possible:

void main() {
  var ReifiedString = String; // Obtain the reified type object for the type `String`.
  if (ReifiedString is Object) { // Same operation as `String is Object`.
    // Here we know that `ReifiedString` is an `Object`, but
    // we knew that already, so we can't do anything extra.
    ReifiedString.toString(); // Can do, not exciting. ;-)
  }
}

Testing that ReifiedString is Object doesn't imply that the type String that ReifiedString reifies has any particular static members or constructors, including hash, hashAll etc.

It's the instance members of the tested type A which must be available as instance members of the reified type object for B when we declare that class B ... static implements A {...}

This means that if A has an int get foo member then the reified type object for B also has an int get foo, and this is guaranteed to be implemented as a forwarder to a static member B.foo.

The reason why I'm emphasizing that it's all about instance members is that we already have the entire machinery for instance members: Late binding, correct overriding, the works.

The static members and the constructors are just used to derive a corresponding instance member that forwards to them, and all the rest occurs in normal object land, with normal OO semantics.

[tatumizer]

@eernstg : I understand each of these points, but they don't self-assemble in my head to result in a sense of understanding of the whole. The problem is terminological in nature. See my previous post about Kotlin.
(The very fact that you have to explain it reinforces the impression that the wording is not perfect. My guess is that we are missing an intermediate concept of "companion object" or similar).

[eernstg]

About Kotlin's companion object, I already mentioned it here. The main point is that you cannot obtain the companion object based on a type argument, you have to denote the concrete class.

This reduces the expressive power considerably, because you can pass the type along as a type parameter and you can pass the companion object on as a regular value object, and then you can use the type as a type and the companion object as a way to access static members and constructors of that type. This is tedious because you have to pass the type and the object along your entire call chain whenever you want to use both.

You could also pass the type alone, but then you can't get hold of the companion object.

Or you could pass the companion object alone, but then you can't use the type (which is highly relevant, e.g., if you're calling constructors).

I spelled out how it is possible to write a companion object manually in Dart in this comment.

With this proposal, we can obtain the "companion object" (that is, the reified type object) for any given type (type variable or otherwise) by evaluating that type as an expression at any time we want, and we can test whether it satisfies a given interface such that we can call the static members / constructors of that type safely.

[eernstg]

@tatumizer wrote:

My guess is that we are missing an intermediate concept of "companion object" or similar

The role of the companion object in Kotlin and Scala is played by the reified type object in this proposal. We could of course also introduce an indirection and just add a SomeInterface get companion getter to the reified type object's interface, but I don't think that's going to help in any way, it's just an extra step for no reason. Does that make more sense?

[tatumizer]

@eernstg : that's where I have to disagree. It's an extra step for cognitive reason, which is a hell of a reason. :-)
But it's not only that! If you start reformulating the proposal in terms of companion object, many problems will resolve themselves automatically. Maybe a companion object is just a mental crutch, but I suspect it's more than that - or else we can get bogged down in hair-splitting about the meanings of words and their superpositions. Please give it a thought.

(Main property of a companion object, apart of its very existence, is that it has a clear type, which is visibly distinct from the type of the object itself, and it's a part of an (explicitly) different hierarchy. The difference is in explicitness).

[eernstg]

If we just use the phrase 'companion object' rather than 'reified type object', would that suffice? I don't think there's any real difference between the members of a companion object in Scala and Kotlin, and the forwarding instance members in this proposal, so the reified type object is the companion object.

There is a difference in that this proposal only populates the companion object with forwarding instance members when the target class has a static implements A clause, and then only with forwarders that implement A.

We could also choose to populate every reified type object with all static members and all constructors. However, I suspect that it's a better trade-off to avoid generating so many forwarding methods because (1) they will consume resources (time and space) at least during compilation, and perhaps the unused ones won't be fully tree-shaken, and (2) they aren't recognized by the static type system if the reified type object doesn't have any useful denotable supertypes (so all invocations would then have to be performed dynamically).

The difference is in explicitness

Good point!

It is indeed an element of implicitness that this proposal works in terms of a 1:1 connection between each targeted static member / constructor and a forwarding instance member of the reified type object. We don't have that kind of relationship anywhere else in the language. The connection is created by specifying exactly how we will take a static member declaration and derive the corresponding instance member signature, and similarly for each constructor.

I don't know how this could be made more explicit without asking developers to write a lot of code that would be computed deterministically anyway (which is basically the definition of redundancy).

For the type, the static implements A clause does specify explicitly which type (in addition to Type) the reified type object will have.

[tatumizer]

If we just use the phrase 'companion object' rather than 'reified type object', would that suffice?

I don't know if that will suffice, but it would certainly be a step in the right direction. When I see the expression "reified type object", my head refuses to operate further - though I can guess what this means, I'm not sure the guess is correct, and the word "reified" especially scares me off (like, WTF: how this reified type object differs from just type object?).

I'll respond to the rest of your comments here later, need time to process :-).

[Wdestroier]

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

True, it's important to be an opt-in feature.
Example: the abstract keyword means the person opted in.

abstract class MyClass {
  // No effect on subtypes.
  static String name() => 'MyClass';

  // Has effect on subtypes.
  abstract MyClass();

  // Has effect on subtypes.
  abstract static MyClass fromMap(Map<String, dynamic> json) =>
    MyConcreteClass(property: json['property']);
}

[tatumizer]

@eernstg:

Here's an arrangement I could understand:

1. every Type object receives an additional getter. let's call it "companionObject". That is, we can say String.companionObject and get a real Object. By naming convention, the type of this object is (strawman) StringCompanion.

print(String.companionObject is StringCompanion); // true
print(String.companionObject.runtimeType == StringCompanion); // true

This is achieved by adding one method to the Type class:

class Type {
  Object companionObject; // just an Object
  // etc...
}

2. If we want to invoke the method of parametrized type, we have to declare the type like this

class Foo<T static implements SomeKnownInterface> {
   bar() {
     T.companionObject.methodFromKnownInterface(...);
   }
}

3. In the class declaration, we have to add "static implements" (no "extends" or "with")

class Foo static implements FromJson<Foo> {
   // no changes to the existing syntax
  static Foo fromJson(String str) { ... }
}

The companion object will only include the methods from the static implements interface(s)

4. If the class doesn't declare static implements, then the associated companionObject will remain empty.

The difference of this design and the original one is that, given a type parameter T, you can write if (T.companionObject is SomeKnownInterface) , but you cannot write if (T is SomeKnownInterface), because the latter doesn't make sense - it's always false, as it is today. Other differences follow from here.
(I apologize in advance for any possible misunderstanding of the current proposal)

WDYT?

(Possible alternative for "companionObject": "staticInterfaceObject" or something that contains the word "static")
(Another alternative: "staticProxyObject", or just staticProxy, and the name of its type is like StringStaticProxy)

[eernstg]

Here's an arrangement ...

Very good! I think I can add a couple of comments here and there to explain why this is just "the same thing with one extra step" compared to my proposal. You may prefer to have that extra step for whatever reason, but I don't think it contributes any extra affordances.

Also, I'll try to demystify the notion of a 'reified type object'.

every Type object receives an additional getter. let's call it "companionObject".

Right, that's exactly what I meant by 'We could of course also introduce an indirection' here.

print(String.companionObject is StringCompanion); // true
print(String.companionObject.runtimeType == StringCompanion); // true

You'd have to use (String).companionObject because companionObject would be an instance getter on the result of evaluating String as an expression, which is what you get by using (String) as the receiver. In contrast, String.companionObject is an error unless companionObject is a static member of the class String or String.companionObject is a constructor (and that wouldn't be useful, because the whole point here is that we want to abstract away from the concrete type such that we can, for example, call constructors or static members of different classes/mixins/etc from the same call site). So companionObject must be an instance member of the value of evaluating String as an expression. So we'd have this:

print((String).companionObject is StringCompanion); // true
print((String).companionObject.runtimeType == StringCompanion); // true

But the value of evaluating a type literal like String as an expression is exactly what I call 'the reified type object' for the type String. It's a perfectly normal object (currently it only has the five Object members, and it overrides operator ==, so it's quite boring. However, we can use it for comparisons like obj.runtimeType == String or MyTypeVariable == String).

The core idea in this proposal (meaning "the proposal in the first post of this issue") is that this object should (1) have instance members forwarding to the static members and constructors of the type which is being reified, and it should (2) have a type that allows us to call those static members and constructors (indirectly via forwarders) in a type safe manner, without knowing statically that it is exactly the static members and constructors of String that we're calling. (If we know that we're operating on the companion object or reified type object of exactly String then we could just as well have used the normal static member invocation mechanism that we have today: String.staticMethod()).

Returning to StringCompanion, this is a type whose interface has instance members corresponding to the static members (and perhaps constructors?) of String. So we can use (String).companionObject.staticMethod() to call a static method staticMethod (let's just say that String.staticMethod exists and is a static method). It will do the same thing as String.staticMethod().

To compare, this proposal will do exactly the same thing in the following way (assuming that String has the clause static implements Interface where Interface is the interface that corresponds to the set of static members and constructors that String wants to support via its reified type object):

print(String is Interface); // true
print((String).runtimeType == Interface); // false

The second query is false because the run-time type is not exactly Interface, it is a subtype of Interface, and it is a subtype of Type. This is again not a problem (in other words, you don't need this to be true) because you can just call the static member or constructor using the syntax we have today if you know exactly what the run-time type of the companion object / reified type object is: You can simply do String.staticMethod() if you know it's String.

If we want to invoke the method of parametrized type, we have to declare the type like this

Here's how to do it in this proposal:

class Foo<T static implements SomeKnownInterface> {
   bar() {
     (T).methodFromKnownInterface(...);
   }
}

The proposal has an extra shortcut: If we encounter T.methodFromKnownInterface(...) where T is a type variable (such that it is definitely a compile-time error today) then this simply means (T).methodFromKnownInterface(...). So you can omit the parentheses around type variables, which makes this kind of invocation syntactically similar to the current syntax C.methodFromKnownInterface(...) where C denotes a class/mixin/etc declaration that actually declares a static member named methodFromKnownInterface.

In the class declaration, we have to add "static implements" (no "extends" or "with")

class Foo static implements FromJson<Foo> {
   // no changes to the existing syntax
  static Foo fromJson(String str) { ... }
}

The companion object will only include the methods from the static implements interface(s)

These statements are true for this proposal as well.

If the class doesn't declare static implements, then the associated companionObject will remain empty.

The corresponding statement for this proposal is that if the class doesn't declare static implements then the reified type object does not have any instance members that are forwarders to the static members or constructors of the corresponding class declaration. (The reified type object in this proposal will still have toString etc., like any other object, but that might well be true for your companion objects as wall. So they are very similar.)

The difference of this design and the original one is that, given a type parameter T, you can write if (T.companionObject is SomeKnownInterface), but you cannot write if (T is SomeKnownInterface), because the latter doesn't make sense - it's always false, as it is today. Other differences follow from here.

In your proposal you can write (T).companionObject is SomeKnownInterface, and in this proposal the exact same thing is written as T is SomeKnownInterface, which does make sense and will evaluate to true if and only if the class/mixin/etc. declaration that corresponds to the given value of T does have the clause static implements SomeKnownInterface (or, silly corner case: if Type <: SomeKnownInterface, e.g., if SomeKnownInterface is dynamic or Object).

I hope this illustrates that the two approaches correspond to each other very precisely, and the only difference is that the companionObject getter is invoked in your proposal in a number of situations, and you simply skip that step in my proposal.

[tatumizer]

@eernstg:
my bad, I don't know why I wrote String.method whenever I meant (String).method - I perfectly understand the differences.

I think I can pinpoint the single place where our views diverge, and it's this:
To explain why "reified type object" (RTO) for one class has different methods than that of another, the types of these "reified type objects" have to be different. E.g. RTO for String may have type _StringTypeObject - it's specific to String. (currently, the runtime type of RTO is _Type; after the change, _StringTypeObject becomes a subclass of _Type).
But I'm not sure such reinterpretation is possible (for the reasons of backward compatibility). Or maybe it is?
(You need to be able to explain to the user why RTO for Foo contains not all static methods of Foo, but only those that are part of declared static interfaces. So if the class name explicitly says FooStaticInterfaceProxy, that would help).
Otherwise, I agree that it's the same idea.

[eernstg]

Great, I think we're converging!

To explain why "reified type object" (RTO) for one class has different methods than that of another, the types of these "reified type objects" have to be different.

That's generally not a problem.

In my proposal, the RTO for a given class has a type which is a subtype of Type (such that current code doesn't break) and also a subtype of the specified static superinterfaces (introduced by static implements).

Currently, we already have a situation where the result returned from the built-in runtimeType getter has type _Type rather than Type, and the same is true for evaluation of a type literal as an expression (hence String is Type). This is just standard OO subsumption, and there's nothing special about the fact that we don't (officially) know the precise type of String used as an expression.

This implies that it isn't a breaking change to make those evaluations yield a result whose type isn't _Type, but types of the form _Type & MetaMembers_Of_String, or something along those lines. As long as the given object has type Type we're happy.

Next step, the static type of an expression that evaluates a type literal that denotes a class/mixin/etc. declaration can include the meta-member mixin. In other words, the static type of String as an expression can be _Type & MetaMembers_Of_String.

This implies that we can safely assign this RTO to a variable with the static implements type:

abstract class StaticFooable { void foo(); }

class A static implements StaticFooable {
  static void foo() => print('A.foo');
}

void main() {
  StaticFooable companion = A;
  companion.foo(); // Prints 'A.foo'.
}

However, we can not use an overriding declaration of runtimeType to improve on the type: It is true that the runtimeType of an instance of A will return an RTO whose run-time type is a subtype of StaticFooable, but the actual receiver type may be some subclass of A which might not static implement StaticFooable.

This means that we don't know anything more specific than Type when we obtain a RTO from a type variable, which is the reason why I'm using a dynamic test (var reifiedX = X; if (reifiedX is StaticFooable) reifiedX.foo();).

It might seem nice and natural if we could make the static interface co-vary with the interface of the base object itself (such that we could use SomeMoreSpecificType get runtimeType; to override runtimeType in every class that static implements SomeMoreSpecificType), but I do not think it's possible: There is no reason to assume that a subclass would have a static interface which is a subtype of the static interface of its superinterfaces. I think the instance member interface and the static interface are simply independent of each other.

However, note that it would certainly be possible for a type argument to use subsumption in static interface types:

abstract class StaticFooable { void foo(); }
abstract class StaticFooBarable implements StaticFooable { void bar(); }

class B extends A static implements StaticFooBarable {
  static void foo() => print('B.foo');
  static void bar() => print('B.bar');
}

void baz<X static extends StaticFooable>() {
  X.foo(); // OK
  X.bar(); // Compile-time error, no such member.
  (X as dynamic). bar(); // Succeeds when `X` is `B`.
}

void main() {
  baz<B>(); // OK, `StaticFooBarable <: StaticFooable` implies that `B is StaticFooable`.
}

[tatumizer]

It might seem nice and natural if we could make the static interface co-vary with the interface of the base object itself (such that we could use SomeMoreSpecificType get runtimeType; to override runtimeType in every class that static implements SomeMoreSpecificType), but I do not think it's possible

Why do you need this SomeMoreSpecificType get runtimeType ?
It would be perfectly fine to leave it as Type get runtimeType. Probably, I'm missing something here.
When we invoke (Foo).runtimeType, we can get ANY type that extends or implements Type. It can be, say FooInterfaceObject, which is declared internally as class FooInterfaceObject extends Type. At least, for the user it should look like this. Under the hood, it can be implemented differently - no one cares how exactly.

Compare with this: we can declare some method as returning num, but the runtime type of the returned value can print double.
Are Type and num fundamentally different in this respect? Why?

To be sure if we are on the same page, please answer this question.
Suppose we have 2 objects obj1 and obj2.
We invoke obj1.runtimeType and get "Foo".
We invoke obj2.runtimeType and get "Foo".
Can we conclude that objects obj1 and obj2 implement exactly the same set of methods?

The static type of expression Foo can remain Type - same as the static type of String, or int. Maybe I said something contrary to that earlier - if so, it was a mistake.

(After re-reading your response, I am not even sure we disagree on anything important, And I do acknowledge the benefits of your proposal, assuming we agree that Foo.runtimeType is not just _Type, but a more specific FooInterfaceObject (or something) that extends Type and has Foo in its name. Then the idea will be very easy to understand, and the description will fit in a single page - in fact, it will be even easier to explain than the "companion" object in Kotlin)

[tatumizer]

After considering it more, the idea of including in RTO only the references to methods from the declared static interfaces might be unnecessary. Whenever the tree-shaker decides to preserve class C, it will most likely have to preserve its noname constructor, too (otherwise, no one can create an instance). Apart from constructors, the classes rarely have static methods, and those that are potentially used could be identified by name (e.g. if someone says (T as dynamic).foo(), the tree-shaker can preserve all methods called foo in all classes potentially passed as T into the class in question.
The names of static methods in most cases are unique. So the restriction won't buy much in terms of size but may damage the logical integrity of a concept. It would be much better to maintain the illusion that all static methods are included in RTO.

---

Another point: I think static interfaces don't make much sense. I can't imagine the situation where a class expects type parameter to implement some static methods without also expecting the instances to implement some specific regular methods.
E.g., some class can compute polynomials over a ring (represented by an interface R), where R must provide static methods for zero and unity, and the instances must define operations of addition and multiplication.
To make this possible, we have to add support for the static abstract methods, e.g.

abstract class Ring<T> {
  abstract T operator+(T other);
  abstract T operator*(T other);
  // ...etc
  abstract static T zero; // SIC!
  abstract static T unity;  
}
class Integer implements Ring<Integer> {
  final int _n;
  Integer(this._n); 
  // ...implementation of operators, 
  static const zero = Integer(0);
  static const unity = Integer(1); 
}

[benthillerkus]

At the risk of this having already been explained and not getting the syntax right, I have a couple questions:

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

  bool operator==(Object other) {
    return other is A && foo == other.foo;
  }
}

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() {}
}

class C implements A<C> {
  const C(this.foo);

  @override
  final int foo;
  
  @override
  void bar() {}

  @override
  C call(int _) => this;
  
  @override
  C named(int _, int _) => this;
}

void main() {
  assert(B(0).runtimeType ==  const C(1));
}

would that be legal?

And would it be possible for a class to both implement and static implement the same class at the same time? If the name conflict can / could be somehow avoided?

And is the override annotation not required / recommended for static implements?

sealed 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() {}
}

void main() {
  final (A) t = B;

  final _ = switch(t) {
    const (B) _ => print("b"),
    // I have to exhaustively check for all classes that static implement A
  };
}

And would something like that be possible?

[eernstg]

@tatumizer wrote, about my remark that one might want to override the return type of runtimeType covariantly:

It would be perfectly fine to leave it as Type get runtimeType.

Agreed. It's common and useful to override a return type covariantly, but it won't work in this case, that's all I wanted to say. Here's an outline of a case where it does work:

abstract class A {
  List<A> get selfInList;
}

class B1 implements A {
  List<B1> get selfInList => [this]; // Override the return type covariantly.
  void b1Thing() {}
}

class B2 implements A {
  List<B2> get selfInList => [this]; // Many subtypes of `A` could do this.
}

void main() {
  var b1 = B1();
  b1.selfInList[0].b1Thing(); // Only type correct because of the covariant override.
}

The reason why it will not work with the "more capable Type objects" is that their type does not "co-vary" with the type of the original object. In other words, the subtype structures at the base level and at the meta level are independent.

Can we conclude that objects obj1 and obj2 implement exactly the same set of methods?

No.

class A {
  void foo() {}
}
class B {
  void bar();
  Type get runtimeType => A;
}

void main() {
  assert(A().runtimeType == B().runtimeType);
}

We do have that property, though, if it is guaranteed that obj1 and obj2 are both instances of a class whose implementation of runtimeType is declared in Object (in which case we also know that they are instances of the same class).

I am not even sure we disagree on anything important

I thought so, too! 😄

I do acknowledge the benefits of your proposal, assuming we agree that Foo.runtimeType is not just _Type, but a more specific FooInterfaceObject (or something) that extends Type and has Foo in its name.

Sounds good! We're in control as developers for these things:

If foo is an instance of a class Foo whose runtimeType is the one from Object then foo.runtimeType is an object whose run-time type is a subtype of Type (it's an implementation specific property whether or not it is actually _Type for objects today, and also with this feature, for most objects).

foo.runtimeType will be an instance of a subtype of FooInterfaceObject if and only if the declaration of Foo has a clause of the form static implements FooInterfaceObject (or static implements T where T is some subtype of FooInterfaceObject). This means that the naming is purely a matter of coding style.

The static type of expression Foo can remain Type

That's different, I think it's crucial that type literals have the best possible type, and in particular that they must have a static type that includes the static interface. So if Foo has static implements FooInterfaceObject then it should be statically recognized as safe to do this:

class FooStaticInterface {
  void staticMethod(int i) {}
}

class Foo static implements FooStaticInterface {...}
class Bar static implements  FooStaticInterface {...}

void main() {
  var metaObject = someCondition ? Foo : Bar;
  metaObject.staticMethod(); // Statically typed and safe.
}

[eernstg]

@tatumizer wrote:

I can't imagine the situation where a class expects type parameter to implement some static methods without also expecting the instances to implement some specific regular methods.

We should most likely be able to specify both, independently.

abstract class StaticRingInterface<T> {
  T get zero;
  T get unity;
}

abstract class Ring<T> static implements StaticRingInterface<T> {
  abstract T operator+(T other);
  abstract T operator*(T other);
  // ...etc
  abstract static T zero; // SIC!
  abstract static T unity;  
}

class Integer implements Ring<Integer> static implements StaticRingInterface<Integer> {
  final int _n;
  Integer(this._n); 
  // ...implementation of operators, 
  static const zero = Integer(0);
  static const unity = Integer(1); 
}

void useIt<R extends Ring<R> static extends StaticRingInterface<R>>(R r) {
  var same = r * R.unity + R.zero;
}

[tatumizer]

@eernstg: thanks! it would take a while for me to comprehend this b1Thing, but meanwhile: don't you think the idea of static abstract methods is more parsimonious (more "Occam's Razor-compliant")?
What are your objections against that?
With "static abstract" methods, you don't have to mangle the natural static method signatures producing a normal-looking "interface" when in practice, you don't need it as a normal interface, and only as a holder for static methods (in your proposal, these abstract methods don't even look like static methods anymore!).
Especially considering that (see Ring<T> example) these 2 interfaces are entangled.
If you need just static methods, you can always declare

abstract class FromJson<T> {
   static abstract T fromJson(String str);
}
class Foo implements FromJson<Foo> {
   static Foo fromJson(String str) {...}
}

I mean, the concept would be much nicer with abstract static methods (IMO).

[eernstg]

@benthillerkus wrote:

would that be legal?

about the following (I added some comments):

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

  // Comment 1 below.
  bool operator ==(Object other) {
    return other is A && foo == other.foo;
  }
}

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() {}
}

// Comment 2.
class C implements A<C> {
  const C(this.foo);

  @override
  final int foo;
  
  @override
  void bar() {}

  @override
  C call(int _) => this;
  
  @override
  C named(int _, int _) => this;
}

void main() {
  // Comment 3.
  assert(B(0).runtimeType ==  const C(1));
}

1. It's an interesting idea that the reified type objects would be able to inherit an implementation of certain instance members. However, I actually think it's too dangerous in practice. In particular, we're used to reified type objects whose equality is system-defined and predictable, and this allows us to get the "obvious" result when we evaluate expressions like List<int> == List<int> (which should be true), or X == String where X is a type variable whose value is int when this expression is evaluated (so that should be false). So my idea was that the reified type objects only static implements a given class, it doesn't inherit any behavior, the entire behavior is obtained by forwarding to static members and/or constructors of the underlying class. So I'd say that the declaration of operator == in A has no effect, and that's also what we want.
2. The declaration of C illustrates that it is possible to have both a static implements A<...> clause in one class A and a plain implements A<...> in a different class C (or it could even be the same class!). The former constrains the static members of A and the latter constrains the instance members of C, and this means that the types A and C are unrelated. They are basically not similar at all.
3. We can have the assertion, and it has no errors at compile time, but it will fail if checked at run time. The reason for this is that B(0).runtimeType is a type which is a subtype of A<B> and a subtype of Type (which means that it has nothing to do with the type C). This subtype of A<B> and Type is implicitly induced during compilation, and there is no syntax that we can use to denote this type (it's similar to a private class in that sense). However, we can assign the reified type object to a variable of type A<S> (where S is B or a supertype of B) is because its type is a subtype thereof, and that allows us to use the static members and constructors of B in a way that doesn't require us to depend on the type B itself.

would it be possible for a class to both implement and static implement the same class at the same time?

Possible (if we can avoid name clashes and other errors), but probably silly. ;-) I can't come up with a situation where this would be useful.

And is the override annotation not required / recommended for static implements?

It could certainly be supported:

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

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

The metadata on constructors and static members would go together with having a static implements clause, and it would indicate that the static members and constructors that have an @override are needed in order to satisfy the static implements ... constraint.

On the other hand, it's probably more readable if this task is handled by a new value, say, @staticOverride.

In any case, it would be recommended to have it on all the constructors / static members which are needed in order to satisfy the given static implements clause, and it would be flagged with a warning if this metadata occurs on a declaration that doesn't play this kind of role.

[eernstg]

@tatumizer wrote:

don't you think the idea of static abstract methods is more parsimonious

I think it's implied that any static abstract declaration in a class/mixin declaration will constrain all subinterfaces to have an implementation (declared in that class/mixin, or inherited from one of its superinterfaces ... (which one?)). I also think that this wouldn't be useful or realistic, because it implies that the static interface and the instance interface co-vary.

In particular, constructors wouldn't fit in with this concept.

I'd expect that different classes have different constructors, and it would be highly impractical to say that "each of the subclasses T of a class C, direct or indirect, must have a constructor T.named(int, int), just because C has a constructor with that signature. Some of them will want to support more, or fewer, or differently typed, parameters.

Another difficulty is that it is unobvious (to me, at least) how we would be able to model the typing of constructors: They return something which is basically the Self type of the given class declaration (a constructor in A returns instances of type A). This is very conveniently modeled using F-bounds (like class B static implements A<B> {...}), but I can't see how an approach based on static abstract methods could cover that use case in a well-typed manner.

[tatumizer]

@eernstg:
one short question: suppose we have type parameter T. According to the proposal, we will be able to (dynamically) find out whether T implements some static interface:

class A<T> {
   foo() {
     if (T is SomeStaticInterface)  {...}
   }
}

Question: can we find out whether the objects of type T implement some regular interface Foo?
Sure, we can impose conditions on T in the declaration class A<T extends Foo>, so the compiler will guarantee that all T's are Foo's, but the question is about the dynamic test.
(Today, it's impossible to do, I guess).

---

I made an effort to understand the example of b1.selfInList, but can't easily see what it illustrates. I think the point where we diverge gets captured in this paragraph:

The reason why it will not work with the "more capable Type objects" is that their type does not "co-vary" with the type of the original object. In other words, the subtype structures at the base level and at the meta level are independent.

Sure, they do not co-vary automatically. But my point is that the mechanism of abstract static methods will FORCE them to co-vary (or, rather, force the author to co-vary them). Without this co-variance, the matters will become very complicated, and the mechsnism will not be used to its full potential out of fear of misunderstanding.

To illustrate:

abstract class HasFromJson<Self> {
  static abstract /* exactly?*/ Self fromJson(String str);
  // for illustration only, I include ALSO a normal method
  abstract void foo();
}
class Point implements HasFromJson<Point> {
   final int x, y;
   Point(this.x, this.y);
   foo() {} // foo implemented
   static Point fromJson(String str) { /* code */}
}
class ColorPoint extends Point { // maybe ERROR: should implement HasFromJson<ColorPoint> - not sure
   final int color;
   ColorPoint(super.x, super.y, this.color);
   // ERROR: static method fromJson not implemented 
}

Here, the compiler will notice that ColorPoint is missing an implementation of fromJson and force the user to write it. (The method foo is still inherited). This logic of the compiler is triggered by the observation that Point class implements HasFromJson, so ColorPoint should do it, too, but the implementation of static method cannot be inherited, so the only way to comply with the interface would be to write a ColorPoint-specific code.

Do you see any problem with the implementation of this mechanism?

(I can argue that even a "plain" method toJson should in fact be implemened as an abstract static method to be sure it captures the entirety of the object, and needs to be re-implemented in every class in the hierarchy. You can always implement it via the delegation to super, if there's nothing else to add)

[eernstg]

Question: can we find out whether the objects of type T implement some regular interface Foo?

When T is available as a type (e.g., T is the name of a type variable, or the name of a class/mixin/etc, possibly with type actual arguments) this can be tested in several ways, including this one:

bool typeArgumentIsFoo<T>() => <T>[] is List<Foo>;

// We can test against non-constant types as well.
bool typeArgumentsAreIncreasing<X, Y>() => <X>[] is List<Y>;

This is somewhat costly because we're creating a new list just to test the subtype relationship between two types, but it works, and it is relatively easy to do (and remember ;-).

If we only have the reified type object (an instance of Type) then we can't test the subtype relationships with other types or other reified type objects.

We could have a feature like Type<T>, in which case we can do this:

bool reifiedTypeObjectIsFoo<X>() => X is Type<Foo>;

The Type<T> proposal could easily coexist with the proposal in this issue.

my point is that the mechanism of abstract static methods will FORCE them to co-vary (or, rather, force the author to co-vary them).

This could be a nice feature to have when we're considering client code where the RTOs are being used (we'd just have X extends SomeBound and that would give us the static interface of SomeBound as well).

However, I'm not convinced that it is possible in practice. I suspect that the static interfaces of classes/mixins/etc in a subtype hierarchy will be independent rather than covarying, and it's going to make the feature considerably less helpful if you must follow that discipline for the static members and constructors of all subtypes.

On the other hand, I did consider having an opt-in mechanism along these lines: We could have a covariant variant of the static implements clause, and it would then be required that every subtype has a static implements clause which is at least as strong as the one in each of its superinterfaces. If there is no static implements clause then it works the same as having the uniquely determined strongest static implements clause of all superinterfaces (and it's a compile-time error if the existing static implements types do not have a minimal value).

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

class B covariant 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() {}
}

class C extends B static implements A<C> {
  C(super.i);
  C.named(int i, int j): super.named(j, i + j);
  static get foo => 2;
  // `static void bar() => B.bar();` implicitly induced (that is, "`bar` is inherited").
}

This would work, and it might be nice to have, but the verbosity of covariant static implements stands out. In any case, this feature could also be added later.

[tatumizer]

This is somewhat costly because we're creating a new list just to test the subtype relationship between two types, but it works, and it is relatively easy to do (and remember ;-).

Indeed! It's the 5th time that I have learned about this trick, and each time I wonder how cute and easy-to-remember it is 😄

I suspect that the static interfaces of classes/mixins/etc in a subtype hierarchy will be independent rather than covarying, and it's going to make the feature considerably less helpful if you must follow that discipline for the static members and constructors of all subtypes.

But I suspect the contrary is true! Deep subtype hierarchies are out of fashion. Some languages don't support hierarchies at all - everything is done through the interfaces. Even if subclassing is supported, people still tend to avoid deep hierarchies. Flutter declares on page one that all the hierarchies are shallow and posits that as a big plus. We need some data points here.

If it turns out that the interface and hypothetical static interface in practice co-vary in the cases of the hierarchy depth=2, then any further generalization doesn't make practical sense. But the cognitive/usability cost of such generalization is high: the difference in user's perception of the feature would be between "WOW" for one design and "WTF" for another.

In any case, I guess the language can always create a view for the user where all the information about interfaces, static interfaces and what-not seems to be encapsulated in the RTO. By overriding "runtimeType", the system can pretend each RTO has an intelligible type name (it can be a private _SomeGeneratedName, if necessary).

WDYT?

(I googled around about the use cases for abstract static methods in C#. They are few and far between. The major motivation for a feature is an abstraction of numbers like Ring<T>. Beyond that, even ChatGPT couldn't provide any non-trivial examples. In C#, as you know, there's nothing like static implements - everything is expressed in terms of normal interfaces with static abstract methods).

[eernstg]

Deep subtype hierarchies are out of fashion.

I think deep subtype hierarchies were basically always less than optimal.

Aside: I guess we should call them subinterface hierarchies in Dart because it's all about nominally introduced subtyping (class B implements A {}, or extends or with or mixin .. on), not about structurally based subtyping (like variance as in List<int> <: List<num> or function type relations like void Function(num) <: void Function(int)). It's only the nominal ones that matter for the ability to co-vary.

Some languages don't support hierarchies at all - everything is done through the interfaces.

I don't think it matters whether a superinterface is reached via an extends edge or an implements edge (or any other kind for that matter) in the superinterface graph. If we have a statically known type and some other type is only known to be a subtype thereof then we would have to enforce that every one of those has a static interface which is a correct override. So the subtype can add new static members / constructors, but when it overrides a static member or constructor in a superinterface (by using the same name), and this name is included in the static interface, then it must be a correct override according to a new definition of whatever that would mean.

Granted, a very deep superinterface graph could be even harder to reconcile with the "static interface must co-vary" requirement than a shallow one. I just think it might be sufficiently inconvenient already with a shallow one.

We need some data points here.

+100.

use cases for abstract static methods in C# ... The major motivation .. is ..Ring<T>.

Not surprising. I would assume that operators play a very important role here because we might want to abstract over them (such that we can have a + b where the type of a and b has several different subtypes with different implementations of operator +, and we'd like to have something which is similar to late binding for instance members of a class).

However, cases like fromJson seem to be very relevant in Dart, so perhaps they would be a good case in C#, too.

One thing which may be worth noting is that static implements can easily be generalized to allow covariant static implements as well, which allows developers to require the co-varying discipline when they need it. I don't think the approach based on abstract virtual members (and abstract virtual constructors?) will generalize in a similarly smooth manner.

[tatumizer]

@eernstg:
I don't understand how even our flagship toJson/fromJson can be implemented with any mechanism discussed so far.
Consider an earlier example of class ColorPoint extends Point. Assume class Point implements JsonSupport<Point> and implements 2 methods of JsonSupport: one is static Point fromJson(String s), another - just a plain String toJson(). But if ColorPoint doesn't say implements JsonSupport<ColorPoint>, we have two options: 1) make it not inherit either method 2) force the author to add `implements JsonSupport - in which case it has to implement BOTH methods (it can't inherit even toJson).

I don't know how C# handles this, and know even less about how dart is going to do it. 😄

(BTW, I don't even know how to implement toJson in Point. This class has to follow some conventions to allow for the possibility of extending it - e.g. by including some tag className: "Point",, but the author has no idea what these conventions are. In most cases, people don't write data objects allowing extensions; but then, why are we focusing on extensions at all?)

[eernstg]

I don't understand how even our flagship toJson/fromJson can be implemented with any mechanism discussed so far.

I'd expect toJson to be a normal instance method returning something like String or Map<String, dynamic> and taking no parameters. They could also use return type Object? or dynamic in order to allow the return type to be a list or a built-in type like int or bool. There could be lots of other approaches, but I'd expect this to cover most of the area. The toJson methods would not create difficulties with overriding because they can all have the exact same signature.

So the interesting part would be fromJson.

This member needs to be a constructor, or it needs to be static, because we're going to receive a String, a Map<String, dynamic>, or something like that, and then we're going to create an instance of a class which may or may not be known statically at the call site.

We could use the static implements feature to enable a really basic version for Point and ColorPoint:

abstract class FromJson<X> {  
  X fromJson(Map<String, dynamic>);
}

class Point static implements FromJson<Point> {
  final int x, y;
  Point(this.x, this.y);
  Point.fromJson(Map<String, dynamic> map): this(map["x"], map["y"]);
}

class ColorPoint extends Point static implements FromJson<ColorPoint> {
  final String color;
  ColorPoint(super.x, super.y, this.color);
  ColorPoint.fromJson(Map<String, dynamic> map): this(map["x"], map["y"], map["color"]);
}

X create<X extends Object>(FromJson<X>> type, Map<String, dynamic> map)  {
  return type.fromJSon(map);
}

void main() {
  var pointMap = {"x": 3, "y": 4};
  var colorPointMap = {"x": 3, "y": 4, "color": "blue"};

  // Basic approach: Just use the constructors directly when we know the type.  
  var p1 = Point.fromJson(pointMap); // OK, `p1` has type `Point`.
  var p2 = ColorPoint.fromJson(colorPointMap); // OK, type `ColorPoint`.

  // `create` can use a reified type object.
  var p3 = create(Point, pointMap); // Type `Point`.
  var p4 = create(ColorPoint, colorPointMap); // Type `ColorPoint`.

  // `create` can also work on the reified type object under a more general type.
  FromJson<Object> type = Point;
  var p5 = create(type, colorPointMap); // Static type `Object`, dynamic `Point`.
  type = ColorPoint;
  var p6 = create(type, colorPointMap); // Static type `Object`, dynamic `ColorPoint`.

  // Finally, we can of course rediscover the type.
  if (type is FromJson<ColorPoint>) {
    var p7 = type.fromJson(colorPointMap); // Type `ColorPoint` again, static and dynamic.
  }
}

At the end we're using colorPointMap all the time because it will handle both types. It is in general a matter of ad-hoc reasoning to ensure that the given JSON map contains the data which will work during construction of an object of the given type, so we probably want to create the reified type object at a point in the code where it is known that the given JSON map will indeed support the creation of that type of object.

This is an example where we really need to avoid the constraint that the static interface must co-vary with the instance interface: Considering your example, if we're forced to have JsonSupport<Point> as a superinterface of Point, then we cannot have JsonSupport<ColorPoint> as a superinterface of ColorPoint: No class/mixin/enum/etc can implement the same interface with two different actual type arguments.

But it's no problem to have static implements FromJson<Point> in Point and static implements FromJson<ColorPoint> in ColorPoint, because this does not mean that Point implements FromJson<Point> or that ColorPoint implements FromJson<ColorPoint>.

Instead, it is the reified type object for Point that implements FromJson<Point>, and it's the reified type object for ColorPoint that implements FromJson<ColorPoint>.

It would even be OK to have class Point covariant static implements FromJson<Point> because FromJson<ColorPoint> is a subtype of FromJson<Point>. All the examples above would still work, and then some:

X create2<X extends Point>(Map<String, dynamic> map) {
  return X.fromJson(map);
}

[tatumizer]

So the interesting part would be fromJson

Apparently, I failed to formulate the question clearly.
Take 2:
The interesting part (to me) is not fromJson. The interesting part is the entanglement between toJson and fromJson!
Please consider the case when both methods are present in the same class.

The class Point implements JsonSupport<Point>, which contains 2 methods - one static fromJSON, another - plain toJSON (just for the sake of an argument, suppose we can declare both in the same interface, WLOG). To comply with the interface. class Point has to implement both methods.

When we create a ColorPoint as a subclass of Point, this ColorPoint, in turn, should either implement BOTH methods, or none - these methods cannot be separated from each other. ColorPoint should not even inherit toJson from Point - for, with such a blind inheritance, it will miss color attribute. We have no way to express this in the language yet, but we can try (using a hypothetical "noninherited" attribute):

abstract noninherited interface JsonSupport<T> {
  abstract Map<...> toJson();
  abstract static T fromJson(Map<...> json);
}

The bottom line: static methods are "entangled" with the instance methods resulting in a single indivisible concept.

This is what happens in the case of abstract numbers: "zero" and "unity" are entangled with the operators + and *, and the whole thing is called a ring. It's impossible to even define zero with no reference to the operations, because, by definition, zero is an element with the property zero+a==a+zero==a for all a from the set - but what is "+"? If "+" is not defined properly, or not defined at all, zero has no meaning. (In a general setting, zero is not necessarily a number. It can be anything that, acting in concert with "+", satisfies the above identities).
Similarly, toJson and fromJson are not two independent operations - they are inverses of each other: A.fromJson(a.toJson()) == a. The design must reflect their inter-dependence by placing them into the same interface.

And that's exactly why C# approach (allowing the combination of instance and static methods defined in the same interface) is the right one.
(C# is also struggling with the concept of virtualness-nonvirtualness in this context, and the whole thing is still a "work-in-progress". I think the idea of noninheritance for the entire interface would be a better formalization).

Interestingly, as soon as we agree that the interface can be marked as non-inherited, the whole "issue" of co-variance just goes away. Nothing really "varies" any longer 😄

(Using covariant/contravariant/invariant terminology, "noninherited" becomes "nonvariant")

[benthillerkus]

Isn't it enough to annotate toJson with @mustBeOverriden https://pub.dev/documentation/meta/latest/meta/mustBeOverridden-constant.html?

Also I don't think toJson and fromJson must be on the same interface.
class MyClass implements ToJson static implements FromJson<MyClass> wouldn't be too bad imo.

[tatumizer]

No, toJson doesn't have to be overridden, and if it IS "overridden", it has to be "overridden" together with fromJson, so the concept of override doesn't even apply here. Please read about the "entanglement" argument.

class MyClass implements ToJson static implements FromJson wouldn't be too bad imo.

It's not "bad". It belongs to the category of "not even wrong" IMO 😄

[eernstg]

(@benthillerkus, it looks like we landed at the same spot. ;-)

@tatumizer wrote:

Please consider the case when both methods are present in the same class.

My immediate take on this is "Sure, no problem":

abstract class FromJson<X> {
  X fromJson(Map<String, dynamic>);
}

abstract class ToJson {
  Map<String, dynamic> toJson();
}

class Point implements ToJson static implements FromJson<Point> {
  final int x, y;
  Point(this.x, this.y);
  Point.fromJson(Map<String, dynamic> map): this(map["x"], map["y"]);
  Map<String, dynamic> toJson() => {"x": x, "y": y};
}

class ColorPoint extends Point static implements FromJson<ColorPoint> {
  final String color;
  ColorPoint(super.x, super.y, this.color);
  ColorPoint.fromJson(Map<String, dynamic> map): this(map["x"], map["y"], map["color"]);
  Map<String, dynamic> toJson() => {"x": x, "y": y, "color": color};
}

X create<X extends Object>(FromJson<X> type, Map<String, dynamic> map)  {
  return type.fromJSon(map);
}

void main() {
  var pointMap = Point(3, 4).toJson();
  var colorPointMap = ColorPoint(3, 4, "blue").toJson();

  // Basic approach: Just use the constructors directly when we know the type.  
  var p1 = Point.fromJson(pointMap); // OK, `p1` has type `Point`.
  var p2 = ColorPoint.fromJson(colorPointMap); // OK, type `ColorPoint`.

  // `create` can use a reified type object.
  var p3 = create(Point, pointMap); // Type `Point`.
  var p4 = create(ColorPoint, colorPointMap); // Type `ColorPoint`.

  // `create` can also work on the reified type object under a more general type.
  FromJson<Object> type = Point;
  var p5 = create(type, colorPointMap); // Static type `Object`, dynamic `Point`.
  type = ColorPoint;
  var p6 = create(type, colorPointMap); // Static type `Object`, dynamic `ColorPoint`.

  // Finally, we can of course rediscover the type.
  if (type is FromJson<ColorPoint>) {
    var p7 = type.fromJson(colorPointMap); // Type `ColorPoint` again, static and dynamic.
  }
}

The class Point implements JsonSupport<Point>, which contains 2 methods - one static fromJSON, another - plain toJSON

I'm arguing that this will not work. So I wouldn't be surprised if we could find further difficulties with that.

these methods cannot be separated from each other

I don't understand why that constraint would be needed, neither technically nor conceptually. I put them into different abstract class declarations because they need to be treated very differently:

One is a plain instance method, easy to handle in every way that I can think of. The other one inherently has no existing instance of the target class to rely on so it must be a static method, and this creates a lot of difficulties with abstraction and subtyping (and this entire issue is basically an attempt to improve on that). Finally, those two methods do not depend on each other.

ColorPoint should not even inherit toJson from Point

This could be turned into a language feature (I think I proposed that, several years ago). But it's kind of a lint because there's nothing that goes wrong technically if ColorPoint does inherit toJson from Point.

But you can't turn every bug into a compile-time error, and it smells like this is an instance of that.

Interestingly, as soon as we agree that the interface can be marked as non-inherited, the whole "issue" of co-variance just goes away

I don't understand why that would be true. Covariance is a relationship whereby some entity works like a monotone (that is, an increasing) function. So a <= b implies f(a) <= f(b). An example is that A <: B implies List<A> <: List<B>.

In this case the covariance constraint would be applied to static members (and constructors?):

// Assume that the static interface is subject to "correct override" checks,
// that is, it must co-vary.

class A {
  static num get foo => 1;
  static num get bar => 1;
}

class B implements A {
  static int get foo => 2; // OK.
  static String get bar => 'Hello!'; // Error.
}

If we want to support subsumption at the static level then we'd allow X.foo where X is a type variable with bound A, and it would be safe (assuming that the entire subtype hierarchy under A does have the "correct override" relationship on every edge in the superinterface graph). This is fine, it works.

But there's no way we can claim that bar is part of the static interface, but due to some declaration (say, a modifier notInherited on A.bar) it is not subject to "correct override" checks in subclasses. This would eliminate the compile-time error above, and it would allow us to invoke X.bar when X is a type variable with bound A, but it would be unsound (it would almost certainly fail at run time, except corner cases like Object myBar = X.bar;).

Hence, I just can't see how a notInherited property could give us (1) soundness, and (2) any notion of fromJson being part of the static interface (such that we can somehow use both Point.fromJson and ColorPoint.fromJson in a way that abstracts away whether it's Point or ColorPoint).

[tatumizer]

To resolve the conceptual difficulties you mentioned, we can establish a different view on the methods like toJson.
It is not an instance method, but a static method syntactically pretending to be an instance method. We could even declare it as a static method of class A (static Map toJson(A a)).
By declaring it a static method, we automatically prevent it from being inherited by subclasses. Plus, we restore the natural symmetry between toJson and fromJson: both become static methods.

I have an impression from your posts that somehow you find it logical that as soon as we put 2 static methods in the same (static) interface, and make the class implement this interface, then the methods become the subject to inheritance. Why? A single static method is not inherited, but two of them are?

In principle, we could avoid placing a mix of static and instance methods into the same interface if we convert the methods like toJson into their static equivalent manually , but if we have operators as part of such an interface, there's no syntax for that in dart (in other languages, there is). The "instance" form of invocation for such methods in just a syntactic convenience - in fact, they are static methods. In which case it goes without saying they are not subject to inheritance.