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