Allow specifying interface implements clauses for the static side of classes

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:

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.

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

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@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.

: 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

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?

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.

James Bromwell (@thw0rted)

James Bromwell (@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.

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

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.

James Bromwell (@thw0rted)

James Bromwell (@thw0rted) Notice these two lines in your code:

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 repetition is exactly what we want to avoid - you defined static create in interface Widget, and have no way to reference that declaration to define the shape of clazz.

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.

ES6 already has first-class support in modern runtimes.

// In Chrome dev tools console
class XYZ { static a(){return 1;} }
let x = new XYZ();
"" + x.constructor; // "class XYZ { static a(){return 1;} }"

It might just be syntactic sugar once you're down in the guts of the engine, but all the seams have been fully plastered over when viewed from the outside. The whole point of ES6 classes is to stop the dichotomy of "one constructor and one prototype".

I don't follow your last paragraph about "where instance member x is expected". An instance of a class that implements an interface with static properties would not have those properties, because that's not what static means. Maybe a more concrete example would clarify your concerns?

MyClass satisfies Statics; would be the preferred way of writing this.
...
So.... close the issue I guess? tada

While this workaround does seem to work well for ensuring type safety, the ergonomics aren't great so I would not call it done.

Aside from the nonobvious and unusual place of declaration, the after-class-definition requirement means it's impossible to get autocomplete like you do with non-static methods and properties since the type checking is completely disconnected from the declaration. It also means any type errors are (1) dumped onto the same single line, (2) very far away from what actually caused the error, especially if the class is long, and (3) nested at least one level deeper than necessary, since the error message always talks about the class itself failing to type check before mentioning which fields are at fault. Lastly, the intent is obscured, since one would reasonably expect a requirement of the class's statics to be declared along with other requirements of the class -- that is, the implements clause, or near it.

In short: yes, it gets the job done, but getting there is unpleasant.

I think going from

const A = class implements IA {
    static f(): number {
        return 1;
    }

    a() {}
} satisfies IAStatic;

to

class A implements IA {
    static f(): number {
        return 1;
    }

    a() {}
} satisfies IAStatic;

would probably address most/all of the concerns in the issue while hopefully not adding much compiler overhead and making the information available to autocomplete. I haven't looked much into the implementation here, but it doesn't seem like that big of an adaptation, especially considering the improved ergonomics it allows.

I think if we have to update the compiler to support a new syntax anyway, class A extends B implements IA satisfies IAStatic {...} is more ergonomic than class A extends B implements IA { ... } satisfies IAStatic. Putting one of the three relationships after the declaration, likely several pages of code later, was already going to be worse. The only advantage is that it can be used as a workaround right now....

Convert crypto.ts to use classes

Convert platform crypto.ts files to use classes

There still seems to be a shortcoming is the current suggested workaround:

Would this be fixed by the syntax change (not requiring a variable) and is there a way to work around this for now, or am I making some sort of mistake and this isn't an issue?

Specifically, I ran into this issue while trying to solve the bigger issue of the type of Test being typeof (Anonymous class). That means that this code:

const aaa: typeof Test = Test.parse();

along with removing the : typeof Test from the static method, gives this error:

The following is a workaround, but it doesn't seem very clean and it would be nicer to not have to do this:

const aaa = Test.parse() as unknown as typeof Test;

The type of Test is still typeof (Anonymous class), however.

Basil (@gBasil)

Basil (@gBasil)

There still seems to be a shortcoming is the current suggested workaround:

Would this be fixed by the syntax change (not requiring a variable) and is there a way to work around this for now, or am I making some sort of mistake and this isn't an issue?

Your code has a bug, the correct return type of Test.parse() is InstanceType<typeof Test>:

interface TestDynamic {
	dyn(): void;
}

interface TestStatic {
	parse(): TestDynamic;
}

const Test = class implements TestDynamic {
	constructor() {}

	static parse(): InstanceType<typeof Test> {
		return new this();
	}

	dyn() {}
} satisfies TestStatic;

This issue has been open for about 5 years now, what's the status?

@gBasil

There still seems to be a shortcoming is the current suggested workaround:

Would this be fixed by the syntax change (not requiring a variable) and is there a way to work around this for now, or am I making some sort of mistake and this isn't an issue?

Your code has a bug, the correct return type of Test.parse() is InstanceType<typeof Test>:

interface TestDynamic {
dyn(): void;
}

interface TestStatic {
parse(): TestDynamic;
}

const Test = class implements TestDynamic {
constructor() {}

static parse(): InstanceType {
return new this();
}

dyn() {}
} satisfies TestStatic;

it could be rewritten with satisfies keyword before class body: (a new feature)

class Test satisfies TestStatic implements TestDynamic { ... }
class Test implements TestDynamic satisfies TestStatic { ... }

Navigation Menu

Repository navigation

Allow specifying interface implements clauses for the static side of classes #33892

Search Terms

Suggestion

Use Cases

Examples

Checklist

Why not `static` members in interfaces?

Why `implements static T`, not `static implements T` ?

47 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Allow specifying interface implements clauses for the static side of classes #33892

Description

Search Terms

Suggestion

Use Cases

Examples

Checklist

Activity

RyanCavanaugh commented on Oct 15, 2019

Why not static members in interfaces?

Why implements static T, not static implements T ?

yandodov commented on Oct 16, 2019

RyanCavanaugh commented on Oct 16, 2019

yandodov commented on Oct 17, 2019

thw0rted commented on Oct 17, 2019

yandodov commented on Oct 17, 2019

thw0rted commented on Oct 17, 2019

yandodov commented on Oct 17, 2019

RyanCavanaugh commented on Oct 17, 2019

thw0rted commented on Oct 18, 2019

47 remaining items

jthoward64 commented on May 14, 2023

thw0rted commented on May 15, 2023

gylove1994 commented on Dec 1, 2023

gBasil commented on Jan 14, 2024

ExE-Boss commented on Jun 26, 2024

Sebastian-Nielsen commented on Jul 6, 2024

eczn commented on Dec 24, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Why not `static` members in interfaces?

Why `implements static T`, not `static implements T` ?