Avoid syntax collision with flow.js and TypeScript

[Jack-Works]

Should we try to avoid syntax collision with flow.js and TypeScript since this proposal will have different semantics than they provided?

Avoid syntax collision

This limits our design space because we cannot design a syntax that is ambiguous when the parse supports both ECMAScript enum and TypeScript enum.

Here is an example of TypeScript enum:

enum Direction {}
enum Direction1 { Up = 1, Down }
enum Direction2 { Up, Down }
const enum Direction3 { Up, Down }

Here is an example of Flow.js enum:

enum Direction {}
enum Direction1 of symbol { Up, Down }
enum Direction2 of string { Up, Down }
enum Direction3 { a, b, ... } // Enums with Unknown Members

Avoid syntax collision creates an ecosystem split because of TypeScript/flow.js users, both TypeScript/flow.js enum and ECMAScript enum are available. Having two enums in TypeScript/flow.js will create confusion for their users.

TypeScript/flow.js enum is shorter than the ECMAScript enum, which might encourage developers to use the TypeScript/flow.js enum if it's possible.

A possible solution is enforcing developers to write the expected member type (#16). The solution given in that issue also resolve the syntax collision.

Not avoid syntax collision

flow.js and TypeScript must use a compiler flag --useECMAScriptEnum like what TypeScript did to the class field --useDefineForClassField.

This also creates a split in the ecosystem. When a library ships .d.ts that includes an enum, it doesn't clear if the enum has semantics specified in this proposal, or it's a TypeScript enum.

[dnalborczyk]

personally I would not try to avoid syntax collisions, as I would leave it to the TypeScript team to figure out how to solve that problem. Typescript enums are quite hard to work with and I usually avoid them if I can, and rather use either a union of string literals or a (frozen) object. Typescript enums have also been created without a design proposal involving a language committee as this proposal will do. the same applies to flow types. just a side note: I love Typescript (but enums are not part of it).

[Jamesernator]

If number type is the default, then for the most part enum Foo { A, B } would be mostly compatible with TypeScript anyway. TypeScript has already had to add flags for public fields which were different than the original transpiled fields TypeScript had, compared to that the differences for enum would probably be even less drastic as patterns for existing enum would probably be mostly covered.