> In addition to generic interfaces, we can also create generic classes. Note that it is not possible to create generic enums and namespaces.
So... arbitrary opinionated restrictions in #TypeScript? Why not generic enums, actually?
Discussion
Loading...
@aartaka What would you use a generic enum for?
Let's say you have enum E<T> {...}. You have a function like this:
function dispatch<T>(e:E<T>): void {
switch (e) {
...
}
}
What goes in the cases?
@csepp numeric tower substitutions, for one. Making enums automatically cast to floats for float-requiring code. Though I didn鈥檛 properly get to floats in TS yet, so I might be missing something.
@aartaka I meant, what would the "case" statements actually look like? What should they compile to? Does the compilation result depend on the concrete type parameter?
@csepp you're right, switch-case doesn't really work with that, because its cases are supposed (?) to be literals of a certain type. Which restricts the usefulness of generic enums in their main use pattern.
I still think that generic enums would be useful for numeric computations as a type casting shortcut
enum Hello {
zero = 0.0,
one = 1.0,
e = 2.7,
pi = 3.14,
}
function whatever<T> (x: Hello<T>) {
switch(x) {
case Hello.zero:
return x + 8;
case Hello.one:
return x * 8;
case Hello.e:
return Math.pow(x, 3);
case Hello.e:
return Math.pow(x, 2) * 10;
}
}
Writing this, I realize that type casting doesn't really work in TS, with this (totally meaningful expression) still resulting in a float:
console.log((3.2 as unknown) as bigint);
So enum casting is actually not useful at all, and thus generic enums don't make sense. But that's not a problem of generic enums per se. It's a more general problem of TypeScript being both super restrictive and surprisingly fuzzy about types, to the point of absurd.
A small Bonfire corner on the internet
This is a small personal instance of Bonfire in the Fediverse.
Automatic federation enabled