Prevent union of enums with same values (non-narrowable unions)

[georeith]

Suggestion

🔍 Search Terms

• enum
• union
• narrowable
• same values

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I would like a configurable option to prevent the union of enums with same values.

📃 Motivating Example

Consider the following example:

enum HorizontalEdge {
  Left,
  Center,
  Right,
}

enum VerticalEdge {
  Top,
  Center,
  Bottom,
}

type Edge = HorizontalEdge | VerticalEdge; // should warn here if configured

const horizontal = HorizontalEdge.Left; // 0
const vertical = VerticalEdge.Top; // 0

const isHorizontalEdge = (edge: Edge): edge is HorizontalEdge => {
  const horizontalEdges: Edge[] = [
    HorizontalEdge.Left,
    HorizontalEdge.Center,
    HorizontalEdge.Right,
  ];
  return horizontalEdges.includes(edge);
};

isHorizontalEdge(vertical); // true
isHorizontalEdge(horizontal); // true

There is no warning from TypeScript that isHorizontalEdge may return true when passed a VerticalEdge.

This could even occur with string enums if the developer is not careful:

const enum HorizontalEdge {
  Left = 'left',
  Center = 'center',
  Right = 'right',
}

const enum VerticalEdge {
  Top = 'top',
  Center = 'center',
  Bottom = 'bottom',
}

type Edge = HorizontalEdge | VerticalEdge;

Warning against unioning enums with same values would prevent this situation and tell the developer that they need to give their enums distinct values or the union can not be narrowed later as it may lead to runtime errors.

💻 Use Cases

Currently it is up to the developer to be aware of this and carefully check their enums do not overlap when unioning them into a type (the developer may not even be aware this enum is later used in an union), the configuration operation would allow you to opt out of this behaviour entering your codebase.

[sandersn]

It cannot be an error to union two different types, so the error would have to be at the use site. Can you propose when and where the error should be issued?

Two more things:

1. Is this error something that every programmer would want on every code base? If not, it should be a lint rule.
2. This surely would cause errors on some existing code. How common is this in existing code?

You could also avoid your particular problem if enum values of different types were not assignable to each other. I believe string enums behave this way.

[frangio]

I believe the right way to address this would be for narrowing to consider enum values. For example:

enum A { A0, A1 }
enum B { B0, B1 }

declare const x: A | B;

if (x === A.A0) {

TypeScript now narrows x to A.A0, but this is unsound. The correct type for x inside the conditional would be A.A0 | B.B0.

[snarbles2]

I don't know if there can be a good general solution to this problem. Enum types are treated as nominal, but their branding is not reified. You can't forbid a union type, yet you can't discriminate such a union. You can forbid certain operators for values with nominally distinct types, but not without blocking valid use cases and breaking things, and you still wouldn't be fully addressing the problem. Even putting a heavyweight solution behind a flag is still a case of a global solution for a local problem, among other problems.

If you have control over the runtime types, I would say that enums are simply the wrong tool for the job. If you don't, it's not going to matter what tool you use. A zero by any name...

TypeScript now narrows x to A.A0, but this is unsound. The correct type for x inside the conditional would be A.A0 | B.B0.

A.A0 | B.B0 isn't correct either. As far as the type system is concerned, type brands are real, even if you don't have a mechanism to probe the values at runtime. Altering that would be a massive breaking change.

[frangio]

Please elaborate on how A.A0 | B.B0 is not correct? And what do you mean by "type brands are real"?

[snarbles2]

You and I both know that A.A0 and B.B0 are actually both just 0. But under the hood the type definitions "expand" to something more like this:

namespace A { 
    export const A0: 0 & {_type: "A"} = 0 as any;
    export const A1: 1 & {_type: "A"} = 1 as any;
}
type A = typeof A.A0 | typeof A.A1;
namespace B { 
    export const B0: 0 & {_type: "B"} = 0 as any;
    export const B1: 1 & {_type: "B"} = 1 as any;
}
type B = typeof B.B0 | typeof B.B1;

The & {_type: "A"} is your type brand. Replace your enum definitions with the above and it becomes more obvious what the problem is.

If x === A.A0 then it's impossible that x === B.B0, because A.A0 and B.B0 have different values for their _type property.

Those type brands aren't really there at runtime, but as far as the type system is concerned, the type brands are real.

If you dismiss the type branding mechanism, then enum types, symbols , and classes with private or #private properties become nominally indistinct.

[frangio]

I'm saying that enum branding is unsound. Symbol branding is not because it accurately reflects runtime behavior, as far as I can tell.

[snarbles2]

So what exactly are you suggesting? It's an express non-goal of Typescript to be completely sound. All other things being equal, more soundness is a good thing, but how would you make enums more sound without breakage? Or would you remove the branding from them entirely? In which case, why have enums at all?

Given that under the hood they're just numbers (in this case), using an enum union without affording yourself some kind of discriminator is a self-inflicted injury.