Allow specifying interface implements clauses for the static side of classes

[hdodov]

Search Terms

class static side syntax interface type expression

Suggestion

Currently, you can only specify the static side interface of a class with a declaration. From the handbook:

const Clock: ClockConstructor = class Clock implements ClockInterface {
  constructor(h: number, m: number) {}
  tick() {
      console.log("beep beep");
  }
}

When I first wanted to do this (before looking at the docs), I tried to do it in this fashion:

class Clock: ClockConstructor implements ClockInterface {
  ...
}

And I was surprised to see that it didn't work. My proposal is to make this a valid syntax as it's more intuitive and understandable.

I believe that forcing class expressions conflicts with TypeScript's design goals:

5. Produce a language that is composable and easy to reason about.

Why use a class expression when there is no need for it? Why change your actual JavaScript logic for something that exists only in TypeScript and not in your production code.

Use Cases

Anywhere you need to set the interface of the static side of a class without having a need to specify it as an expression.

Examples

Take the example from the playground:

interface ClockConstructor {
  new (hour: number, minute: number);
}

interface ClockInterface {
  tick();
}

class Clock: ClockConstructor implements ClockInterface {
  constructor(h: number, m: number) {}
  tick() {
      console.log("beep beep");
  }
}

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

Ref #14600

We discussed #14600 at length and agreed that the syntax static T in the implements list of a class would be a reasonable place to allow this:

interface X {
  x: string;
}
interface Y {
  y: string;
}
interface Z {
  z: string;
}

// OK example
class C implements Y, static X, Z {
  static x: string = "ok";
  y = "";
  z = "";
}

// Error, property 'x' doesn't exist on 'typeof D'
class D implements static X {
}

Why not static members in interfaces?

#14600 proposed the syntax

interface X {
  static x: string;
}

This is problematic for a couple reasons.

First, it seems to create a totally meaningless thing:

interface X {
  static x: string;
}
function fn(arg: X) {
  // arg has... no members?
}
// Is this a legal call?
// There doesn't seem to be any reason to reject it,
// since 'fn' can't illegally access anything that doesn't exist
fn({ });

Second, there would be no way to access a static member through an interface type that declared it!

interface X {
  static x: string;
}
function fn(arg: X) {
  // How do I get to ctor(arg).x ?
}

You would need to have some auxiliary keyword to turn an interface into the static version of itself:

interface X {
  static x: string;
}
// Syntax: ????
function fn(arg: unstatic X) {
  arg.x; // OK
}

Simply moving the static logic to the class syntax makes this substantially simpler, and (critically) allows classes to implement types that weren't written using the hypothetical interface I { static property: T } syntax.

Why implements static T, not static implements T ?

In the presumably-usual case of one instance and one static heritage member, this is substantially cleaner:

class WidgetMaker implements Factory, static FactoryCtor {
  // ...
}

vs

class WidgetMaker implements Factory static implements FactoryCtor {
  // ...
}

[hdodov]

@RyanCavanaugh I understand your points and agree with all of them. But I don't understand what's the issue with my proposed syntax without the static keyword. I mean, instead of this:

class C implements Y, static X, Z { }

Why not this:

class C: X, Z implements Y { }

Your syntax could be read the correct way like this:

class C implements (Y), static (X, Z)

but due to the commas, it could also be read like this:

class C (implements Y), (static X), (Z)

which would make Z appear out of place. It could even be read like this:

class C implements (Y, static X, Z)

as if C implements Y, Z and a static X which makes no sense. I think the issue here is that the comma is used as both a separator for symbols and keywords.

My proposal has a clear separation of the static and instance sides:

class |C: X, Z| implements |Y, T| { ... }
------|static--------------|instance-----

Yours doesn't:

class |C| implements |Y, T|, static |X, Z| { ... }
------|static--------|instance------|static-------

I just think my proposal leaves less ambiguity.

Some other benefits:

• No use of the static keyword. It was designed for usage inside the class body and if you avoid using it, you'll avoid assigning another TypeScript-only meaning to it
• Members of X and Z are visually closer to C, which makes more sense since you'll be using C.memberOfX and C.memberOfZ
• It's consistent with other keywords. You've got let foo: string and const bar: number. Adding class C: X {} simply follows that pattern
• It's shorter

And to clarify, I'm talking about syntax only. No functional differences.

[RyanCavanaugh]

: in TypeScript always means "is of type", but implements has a different meaning ("is assignable to"). IOW the implied semantics of : are

interface P {
  x: number;
}
class C: P {
  static x: number;
  static y: number;
}
C.x; // OK
C.y; // Not OK; only members of P are visible

the same way that this works (disregarding excess property checks):

interface P {
  x: number;
}
const C: P = { x: 0, y: 0 };
C.x; // OK
C.y; // Not OK; only members of P are visible

[hdodov]

I see. To clarify, would static act as a modifier? If I have:

class C implements Y, static X, Z { }

I should read it as "C implements interface Y, interface X as static, and interface Z" instead of "C implements interface Y and interfaces X and Z as static," right?

When I initially read your comment, I thought static would act like implements and you list items after it. Instead, it would act as a modifier to the items of implements?

So if I have an interface X that must be type-checked in both the instance side and the static side, I would do:

class C implements X, static X { }

Is that right?

[thw0rted]

I don't really follow Ryan's goals in his second post here.

it seems to create a totally meaningless thing: // arg has... no members?

If you made an class with only static methods then you couldn't do much with instances of it either.

there would be no way to access a static member through an interface type that declared it

I don't think that's the point. The reason I want to see static in an interface is to avoid needing to split a mix-in definition:

interface Widget {
  static create(): Widget;
  x: number;
}

class A implements Widget {
  static create(): A { ... }
  x: number = 1;
}

function factory(clazz: {create(): Widget}): Widget {
  const ret = clazz.create();
  ret.x = 10;
  return ret;
}

This is cleaner than the alternative, where I'd have to have separate a WidgetConstructor interface and static implement it. That feels clunky and leads to the potential confusing cases @hdodov lists a few posts back, where there isn't really a "right" way to visually parse the sequence of keywords.

[hdodov]

@thw0rted the constructor and the instance are two completely separate entities. In JavaScript, the API of one is not connected in any way to the API of the other. Because they have different APIs, they probably function differently as well—you can't use a constructor as an instance and vice-versa. Therefore it makes sense to define their types with two separate interfaces.

Your example could be rewritten as:

interface Widget {
  x: number
}

interface WidgetCtor {
  create(): Widget
}

class A implements Widget, static WidgetCtor {
  static create(): A { ... }
  x: number = 1;
}

I personally think that's better.

Even in your example, the Widget interface has a method create() that should return a Widget interface... that should also have create() and return a Widget with create() and so forth? Separating those types in two interfaces solves that problem.

---

Also, what if you have an object that is Widget-like? If you do let obj: Widget it becomes really confusing that this object uses an interface that has a static create() method. By adding a static member to an interface, you imply that it has a static and an instance side and can therefore be used in classes only. Why limit yourself like that? By specifying two interfaces, you avoid that problem too.

[thw0rted]

You say they're not connected in any way, but you still write both constructor (static) methods and instance methods inside the same class { } block, right? That's what I'm saying in my previous comment. There's a certain parallelism in the single-interface version, one interface that describes (a portion of) one class, that's lacking in the two-interface version you describe.

As for the static create() method of let obj: Widget, can't I call obj.constructor.create() if I want to? I'm not an expert in how ES6 classes differ from constructor functions with prototypal inheritance, but I can say that this at least works in Chrome and Node, whether or not it's "correct".

[hdodov]

but you still write both constructor (static) methods and instance methods inside the same class { } block

Yes, because in terms of JavaScript, you have no reason to separate them. When a class extends another class, it extends both the instance and the static side. Don't forget that classes are just syntactic sugar. In the end, all static members appear on the class (constructor) itself, while the instance methods appear in its prototype. So they are separated in JavaScript as well.

There's a certain parallelism in the single-interface version, one interface that describes (a portion of) one class

Yes, but what value does that give you? You can't describe one class. You describe one constructor and one prototype. You describe two things at once which, in the realm of types, complicates things. Logically, they describe "one class" but they serve a different purpose. One might even say, they're different types. And types is what TypeScript is interested in.

can't I call obj.constructor.create()

Yes, you can. But that's different from obj.create(). A class X with static create() would have its method called with X.create(). Saying an object has the same interface would imply that it should have obj.create(), right? But (back to your example) if static properties are assigned to obj, where should the instance member x be expected? obj.x? Why are suddenly static and instance referring to the same thing? Because we united them in an interface and we shouldn't.