From the original proposal

As in the title, and as discussed extensively here, it would be very helpful to allow enums of types other than number. At the very least, if allowing arbitrary types is too much work, string enums should be allowed. The current codegen for enums actually works with strings as-is, the compiler just flags errors.

Consider:

enum Dog{
Rover = 'My Dog',
Lassie = 'Your Dog'
}

alert(Dog.Rover);

As of 0.9, this gets to compiled to:

var Dog;
(function (Dog) {
Dog[Dog["Rover"] = 'My Dog'] = "Rover";

Dog[Dog["Lassie"] = 'Your Dog'] = "Lassie";
})(Dog || (Dog = {}));

alert(Dog.Rover);

which is 100% functioning JavaScript that works as you expect it to.

In addition, the whole concept of "overloads on constants" would be a lot cleaner with a string-based enum:

interface Document {
createElement(tagName: TagName): HTMLCanvasElement;
}

enum TagName{
Canvas = "canvas",
Div = "div",
Span = "span"
}

var a = createElement(TagName.Canvas); //a is of type HTMLCanvasElement

Closed Jul 28 at 5:18 PM by jonturner

As part of our move to GitHub, we're closing our CodePlex suggestions and asking that people >move them to the GitHub issue tracker for further discussion. Some feature requests may already >be active on GitHub, so please make sure to look for an existing issue before filing a new one.

You can find our GitHub issue tracker here:
https://github.com/microsoft/typeScript/issues

jhlange on 19 Nov 2014

Changed the one example from the original for the Document interface. It seems that you would only specify the name of the enum.-- Values passed in would become bounded to the use of the enum constants (and possibly to free-form string literals, where their values can be statically determined to be within the enum's domain values)

jhlange on 19 Nov 2014

@jhlange I think tagged unions would automatically cater for this use case nicely : https://github.com/Microsoft/TypeScript/issues/1003

basarat on 19 Nov 2014

@basarat That seems interesting from a theoretical standpoint, and I can definitely see uses for it.

It would solve my case.--At least giving some level of intellisense and compile-time validation.

I personally believe accessing enum constant fields makes for a much more natural experience for non-functional languages (and at least has parity with enums, which is what they they really are. I really don't think we should create a new concept for a construct that already exists. That will be confusing to too many people).

jhlange on 19 Nov 2014

I would love this when I deal with C++ enums compiled by Emscripten.

// C++
enum Month {
  Jan, Feb, Mar
};

// I can do this, but they really are not numbers!
declare enum Month {
   Jan, Feb, Mar
}

interface EmscriptenEnum {
  value: number; /* some more properties ... */
}
interface Month extends EmscritenEnum {
}
declare module Month {
   var Jan: Month;
   var Feb: Month;
   var Mar: Month;
}
// Month.Jan.value == 0, Month.Feb.value == 1, ...

saschanaz on 19 Nov 2014

C#/C++ lets you define base type of enum, although restricted to numeric type. I would like to be able to do the same but generalized to arbitrary type.

It should work with builtin types like string, so:

enum Foo extends string {
    BAR,
    BAZ = "surprise"
}

compiles to:

var Foo;
(function (Foo) {
    Foo["BAR"] = "BAR";
    Foo[Foo["BAZ"] = "surprise"] = "BAZ";
})(Foo || (Foo = {}));

but also user types, to handle enum object pattern that is used by enums in Java and common in other languages (as requested above):

interface IFoo {
    id: string;
    code: number;
}
enum Foo extends IFoo {
    BAR = { id: "BAR", code: 123 },
    BAZ = { id: "", code: 0 }
}

compiles to:

var Foo;
(function (Foo) {
    Foo["BAR"] = { id: "BAR", code: 123 };
    Foo["BAZ"] = { id: "", code: 0 };
})(Foo || (Foo = {}));

Perhaps with a convention that if interface has fields id and/or code (or ordinal as in Java) they can be omitted in initializer and filled by compiler.

mwisnicki on 30 Dec 2014

👍5

How would this work?

enum Test {
    Foo = "Bar",
    Bar = "Baz",
    Baz = "Foo"
}

enoshixi on 30 Dec 2014

Either compilation error or omit generation of reverse mapping for Bar. I'm not sure which one I prefer.

mwisnicki on 31 Dec 2014

In fact I'd prefer if TypeScript didn't generate reverse mapping in the same object. Perhaps all reverse mappings (for number based enums too) should go inside some property, say Test.__reversed.

mwisnicki on 31 Dec 2014

In my mind these really need to compile down to plain strings. String enums
are already heavily used in json objects for Web services. In my opinion
this is one of the main use cases for string based enums.-- another example
is in the second post-- being able to define the domain values for
predefined Javascript apis.

If it isn't possible to define strongly typed interfaces for these cases,
because typescript uses a different methodology in its implementation, the
implementation would be purely academic.
On Dec 30, 2014 3:16 PM, "Marcin Wisnicki" [email protected] wrote:

In fact I'd prefer if TypeScript didn't generate reverse mapping in the
same object. Perhaps all reverse mappings (for number based enums too)
should go inside some property, say Test.__reversed.

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/1206#issuecomment-68409570
.

jhlange on 31 Dec 2014

I think the first thing should be strings const enum.
This is definitely the most useful feature.
Many APIs has JSON with small amount of possible string values and currently you must use 'string' type rather then a correct subset.
In that case I even think the names are not needed since you can pass only the correct string.

const enum A {
 "x",
 "y",
 "z"
}

var a : A;
a = // Intellisense suggest "x", "y" or "z"
a = "x"; // OK
a = "b"l // Error

NN--- on 28 Jan 2015

My concern with the const enum approach is that it will lead to cases where the value can not be determined to be conforming when being passed into an API. (would this be a warning?, what happens if you get that warning? do you have to add casts all over the place to mitigate the warning?).

If you treat them as something that can never be converted to or from a string, they will do exactly what they need to do.-- It should work exactly like the integer enums, with the exception that the values are strings. I think it would be fine if the keys and values are locked together, meaning that

const enum A {
 "x",
 "y",
 "z"
}

Could be fine, but any string assignments without casts should fail.

public myfunc(someRandomInput: string) {
var a : A;
a = // Intellisense suggest A.x   A.y   A.z
a = "x"; // Error, it is overkill to support this special case. Just use A.x like a regular enum
a = A.x; // OK
a = "b"; // Error
a = someRandomInput; // Error, can not always be determined to be conforming.
}

In cases where they are converted from a string, a cast should be used.-- But even then, behavior like that can indicate that an input did not come from a proper source.

Additionally, this will help tooling like the the schema validation/generators to appropriately generate the appropriate validation code.-- Schema validation is going to become even more important in times to come.--One of my big concerns with javascript is general is the lack of validation.-- Now that people are running servers on this stuff.

As far as I can tell, the bulk of the work needed to get this done is removing one validation/compiler error against enum definitions (assigning types other than number).-- There might be some smarts to make sure people don't directly assign numbers to enum, but they shouldn't be doing that without a cast anyway either...

jhlange on 20 Feb 2015

How about using generics for enum?
Current existing enum means enum<number>. So we can extend it to enum<string> or other types:

enum<string> Foo1 {
    BAR, // default value is "BAR".
    BAZ = "x" // also you can specify the vaule.
}
var e: Foo1 = Foo1.BAR; // ok
var s: string = Foo1.BAR; // ok
var n: number = Foo1.BAR; // error

enum<boolean> Foo2 {
    BAR = true, // assigning is required. only number and string enum have default value.
    BAZ = false
}

You can use every type for enum like enum<YourFavoriteType> and there is no breaking change.

teppeis on 25 Feb 2015

👍21

Base type syntax makes more sense IMHO and is already familiar to C# developers.

mwisnicki on 25 Feb 2015

+1 for the generics suggestion.

bvaughn on 11 Mar 2015

and Closure Compiler uses @enum {string}, similar to generics.

/**
 * @enum {string}
 */
var Foo = {
  BAR: 'BAR',
  BAZ: 'BAZ'
};

Also default type of enum in Closure is number. It's in common with TypeScript's case.

If the type of an enum is omitted, number is assumed.
https://developers.google.com/closure/compiler/docs/js-for-compiler

teppeis on 22 Mar 2015

👍1

+1 for the generics syntax. I just need some sort of functionality. Here's my use case: I'm wanting to convert this bit of ES6 + Lodash into something I can more conveniently statically check. (Note: the boilerplate is because I use it for other things as well, things that would have to be generated at build time to statically type-check.)

// Enum
const tokenTypes = makeEnumType(([value, length]) => ({value, length}));

export const Tokens = tokenTypes({
    OpenCurved:   ['(', 1],
    CloseCurved:  [')', 1],
    OpenBracket:  ['[', 1],
    CloseBracket: [']', 1],
    OpenCurly:    ['{', 1],
    CloseCurly:   ['}', 1],
    Identifier:   ['Identifier', 0],
    String:       ['String', 0],
    EOF:          ['EOF', 0],
});

// Utilities
function deepFreeze(obj) {
    Object.freeze(obj);
    _.forOwn(obj, value => typeof value === 'object' && deepFreeze(obj));
    return obj;
}

_.mixin({
    removeProto(obj) {
        let ret = Object.create(null);
        _.forOwn(obj, _.partial(_.assign, ret));
        return ret;
    },
    freeze: deepFreeze,
});

function mapObject(obj, f) {
    let ret = Object.create(Object.getPrototypeOf(obj));
    forOwn(obj, (value, i) => ret[i] = f.call(obj, value, i, obj));
    return ret;
}

function makeEnumType(transformer) {
    return obj => _.chain(mapObject(obj, transformer))
        .removeProto()
        .freeze()
        .value();
}

The best I can currently do in the first case is this (the second is similar):

interface TokenType {
    type: string;
    value: string;
}

function type(value: string, length: number): TokenType {
    return {value, length};
}

class TokenTypes {
    // This shouldn't be called as a constructor...but it still type-checks.
    static OpenCurved: TokenType   = type('(', 1);
    static CloseCurved: TokenType  = type(')', 1);
    static OpenBracket: TokenType  = type('[', 1);
    static CloseBracket: TokenType = type(']', 1);
    static OpenCurly: TokenType    = type('{', 1);
    static CloseCurly: TokenType   = type('}', 1);
    static Identifier: TokenType   = type('Identifier', 0);
    static String: TokenType       = type('String', 0);
    static EOF: TokenType          = type('EOF', 0);
}

With the above syntax, I could use the following:

enum<TokenType> TokenTypes {
    OpenCurved   = type('(', 1),
    CloseCurved  = type(')', 1),
    OpenBracket  = type('[', 1),
    CloseBracket = type(']', 1),
    OpenCurly    = type('{', 1),
    CloseCurly   = type('}', 1),
    Identifier   = type('Identifier', 0),
    String       = type('String', 0),
    EOF          = type('EOF', 0),
}

This is where enums can really help.

(The boilerplate is mainly for places where a preprocessor would be helpful.)

isiahmeadows on 17 May 2015

@jbondc I like it.

You've picked the simple, obvious and intuitive solution, that can enforce type safety in many of the situations that some of the above options can't without a full static analysis of a program.-- It additionally would support creating straight forward domain bound json schma validations right from the typescript definition.

Any interest in #2491 ?

jhlange on 31 May 2015

+1 for this and I am suggesting supporting all primitive types for enum values. Just like Swift. This is the syntax in Swift which I really like:

enum Audience: String {
    case Public = "Public"
    case Friends = "Friends"
    case Private = "Private"
}

mohsen1 on 16 Jun 2015

I would like to mention that, because of ECMAScript language limitations
themselves, const enums should be limited to non-Symbol primitives. Because
{} !== {} and Symbol("foo") !== Symbol("foo"), other enums can't be
inlined.

I do feel this would be incredibly useful, though.

On Tue, Jun 16, 2015, 16:41 Mohsen Azimi [email protected] wrote:

+1 for this and I am suggesting supporting all primitive types for enum
values. Just like Swift. This is the syntax in Swift which I really like:

enum Audience: String {
case Public = "Public"
case Friends = "Friends"
case Private = "Private"
}

—
Reply to this email directly or view it on GitHub
https://github.com/Microsoft/TypeScript/issues/1206#issuecomment-112563174
.

isiahmeadows on 16 Jun 2015

+1 for the generics syntax.
+1 for jbondc proposal for primitive type / non primitive type management
It would be useful emit primitive enum value for primitive type enums:

enum myStringEnum < string > {
   one = "myOneValue",
   two = "myTwoValue",
   three = "myThreeValue"
}

var value = myStringEnum.one; //emits 'var value = "myOneValue" /* myStringValue.one */'

emit inline value for primitive types (number, string, boolean ...) is very useful because the enum declaration does not need to be emitted in javascript but is used only to enforce compile-type validation

Gambero81 on 5 Jul 2015

👍1

@Gambero81 are you aware of const enums for the purposing of skipping emit like you want?

danquirk on 6 Jul 2015

@danquirk const enum are great, but attually does not support generics type but is only for numeric type..

Gambero81 on 7 Jul 2015

Also const enums should be restricted to primitive types, and the whole reason they aren't emitted is to lessen code size (especially minified), which would _not_ usually be the case with other types, such as strings and booleans.

But as for normal enums of non-numeric types, this definitely should be possible. Currently, there is little reason to prefer a normal enum over a const enum, and this would wonderfully fix that.

I do have (another) possible syntax, in case you all might like it:

function type(ch: string, length: num): TokenType {
    // code...
}

enum TokenTypes: TokenType {
    OpenCurved   = type('(', 1),
    CloseCurved  = type(')', 1),
    OpenBracket  = type('[', 1),
    CloseBracket = type(']', 1),
    OpenCurly    = type('{', 1),
    CloseCurly   = type('}', 1),
    Identifier   = type('Identifier', 0),
    String       = type('String', 0),
    EOF          = type('EOF', 0),
}

isiahmeadows on 7 Jul 2015

Coming from the Java world I really miss the ability to define methods on my enums. Would really like for enums to be full class citizens but still able to be used in switch statements (with auto complete support)

Allows for things like:

var planet = Planet.fromOr(myForm.planetSelect.selectedIndex,Planet.Earth)
myForm.swallowEnabled.checked=Planet.Earth.canSwallow(planet);

Example enum:

enum Planet {
     private label:string; <--custom property
     private size:string; <--custom property
     private orbit:number; <--custom property

     Mercury("Mercury",1,1),Venus("Venus",2.8,2),Earth("Home,3,3)...; <--declare 'constants'

     Planet(label,size,orbit){ <--private constructor
       .....
     }

     //a custom instance method
     public canSwallow(planet:Planet):bool { //<--custom method
        return planet.size < this.size;
     }

     public isCloserToSun(planet:Planet):bool { //<--custom method
        return planet.orbit < this.orbit;
     }

     //all functions below auto generated, or implemented in base enum. Shown here in semi typescript

     //convert from string, number or type or use given default
     public static fromOr(nameindexOrType:string,defVal:Planet=null):Planet { //<--auto generated
        var e = from(nameindexOrType);
        return e==null?defVal:e;
     }

     //convert from string, number or type or return null
     public static from(nameindexOrType:string):Planet { //<--auto generated
       if(nameindexOrType == null){ return null; }
       if(typeof(nameindexOrType) =='Number'){
         switch(nameindexOrType){
           case 0:return Planet.Mercury;
           case 1:return Planet.Venus;
           ...
        }
      }if(typeof(nameindexOrType) =='String'){
         nameindexOrType = nameindexOrType.ToUpperCase();
         switch(nameindexOrType){
           case 'MECURY':return Planet.Mercury;
           ...
        }
      }
      return null;
    }

    public static get names():string[] { //<--auto generated
       return ['Mercury','Venus','Earth',...];
    }

    public static get values():Planet[] { //<--auto generated
       return [Planet.Mercury,Planet.Venus,Planet.Earth',...];
    }

  }
}

internally there would also be a field called 'index' and 'name' which are used for comparison checks (or just one of them)

If no custom properties or methods, then everything compiled down to a number or a string only.

bertvanbrakel on 10 Jul 2015

@bertvanbrakel I like your idea, but I think that may fit better as another bug, and also, this may fall under "Not yet". Another thing, IMO, there aren't a lot of use cases for having methods on enums, anyways, since they can easily become too coupled to the enum, and hard to generalize.

isiahmeadows on 10 Jul 2015

So far, here's the possible syntaxes I've found here...

// 1.
enum Enum extends string {
    Foo, // "Foo"
    Bar = "something",
}

// 2.
enum<string> Enum {
    Foo, // "Foo"
    Bar = "something",
}

// 3.
enum Enum: string {
    Foo, // "Foo"
    Bar = "something",
}

WDYT?

isiahmeadows on 10 Jul 2015

@bertvanbrakel You can already do this:

enum Color { Red, Green, Blue }
module Color {
  export function getFavorite() { return Color.Green; }
}

RyanCavanaugh on 10 Jul 2015

He wants methods on enum values (objects), similar to Java enum.

mwisnicki on 10 Jul 2015

there are many good proposal, but the question is: when will be sheduled and implemented? there is a roadmap for this task?

Gambero81 on 10 Jul 2015

@Gambero81 The "needs-proposal" tag is that this needs a more formal proposal before it actually gets implemented, including type-checking semantics, required JS emit, etc.

isiahmeadows on 10 Jul 2015

+1 for more versatile enums. Also +1 @bertvanbrakel's proposal. Having enums with multiple properties, private constructors and methods all together in a single/self-contained unit of code is very useful and safe from a developer's pov and useful for testability.
In addition to defining methods, being able to implement interfaces is also quite useful.

Here's an example of a useful Java enum; in it the 'value' property allows to make the enum usage independent of the enum ordinal values; this allows to avoid common issues with enum values reordering and the like that often bite beginners.

public enum DeploymentStatus implements InternationalizedEnum {
    PENDING(100, "STATUS_PENDING", "status.pending"),
    QUEUED_FOR_RELEASE(110, "STATUS_QUEUED_FOR_RELEASE","status.queuedrelease"),
    READY_FOR_RELEASE(120,"STATUS_QUEUED_RELEASE","status.readyrelease"),
    RELEASING(130,"STATUS_RELEASING","status.startedrelease"),
    RELEASED(140,"STATUS_RELEASED","status.suceededrelease"),
    QUEUED(200, "STATUS_QUEUED", "status.queued"),
    READY(300, "STATUS_READY", "status.ready"),
    STARTED(400, "STATUS_STARTED", "status.started"),
    SUCCEEDED(500, "STATUS_SUCCEEDED", "status.succeeded"),
    FAILED(600, "STATUS_FAILED", "status.failed"),
    UNKNOWN(700, "STATUS_UNKNOWN", "status.unknown"),
    UNDEFINED(0, "", "status.undefined");

    private final int value;
    private final String code;
    private final String messageCode;

    private DeploymentStatus(final int value,
                             final String code,
                             final String messageCode) {
        this.value = value;
        this.code = code;
        this.messageCode = messageCode;
    }

    public String getCode() {
        return code;
    }

    public int getValue() {
        return value;
    }

    public String getMessageCode() {
        return messageCode;
    }

    public static DeploymentStatus parse(final Integer id) {
        DeploymentStatus status = DeploymentStatus.UNDEFINED;
        if (id != null) {
            for (DeploymentStatus entry : DeploymentStatus.values()) {
                if (entry.getValue() == id) {
                    status = entry;
                    break;
                }
            }
        }
        return status;
    }

    public boolean isFinalStatus() {
        return this == SUCCEEDED || this == FAILED || this == UNKNOWN;
    }
}

dsebastien on 15 Jul 2015

@dsebastien +1 That's almost the use case I needed.

I did find that for my particular use case, it just needed refactored.

isiahmeadows on 15 Jul 2015

@jbondc

The emit is the same but the compiler should treat the entire object as an immutable/const structure.

What about method calls? You have to partially evaluate the code to figure that out.

isiahmeadows on 16 Jul 2015

I stick with my idea that the enums should remain self-contained as that's the cleanest; having to create a separate class just for the purpose of 'linking' it from an enum doesn't make much sense, assuming that the concept it describes is an element of the enum and the operations that it supports. Indeed it would make it much closer to a class but with hard restrictions :)

Also, i don't know if having a mutable enum entry is a good idea at all, it's the kind of thing that would get abused and would lead to side-effects. For me, enums should be as immutable as can be ^^

dsebastien on 16 Jul 2015

It would be great if this feature accurately reflects how the APIs people use today are structured (see the original few comments). The whole purpose of typescript is to introduce a basic level of type safety, not implement features from functional languages, etc. The use cases that already exist to support this have already been defined. Some of these include:

By the browser standards (example: document.createElement(elementType: HtmlElementType) )
By well established javascript libraries ( element.on(eventType: EventType) ) https://api.jquery.com/on/
Basically every web api on the internet ( units of measure, etc in example https://developer.yahoo.com/weather/ )
By the return value of JSON.parse() and stringify() (just look at your own projects, around serialization of types)
by popular server side libraries http://expressjs.com/4x/api.html#app.onmount
Probably lots more that I'm not thinking about

If enums become complex types, tagged unions, or any of the other more complex suggestions in this thread, they will be relatively useless for type safety (the primary goal of typescript), as they will not be usable in scenarios surrounding any current APIs (or in the case of tagged unions, you'd still be compatible, but would the type safety can't be inferred without a full static analysis of the project, which typescript does not do).

Many of the comments here have a lot of academic merit, but they simply do not reflect interoperability with any of the built in APIs, and therefore will deliver minimal value.

jhlange on 16 Jul 2015

_Edit 1: add type inference based on first entry_
_Edit 2: It's now a gist_

I'm going to take a stab at a more concrete proposal, but first, I'd like to say the following:

Much of the reason people are pushing for enums of type other than number are for string enums (we all know they are necessary) and type-safe enums. Also, occasionally, object enums come in handy, so why not support that.
I don't like the current syntax floating around, because it's too similar to interface key type declarations, instead of a variable type or enum property. Also, it doesn't make a whole lot of sense to me in theory - the semantics of current enums are closer to that of the following:

ts enum Foo { [prop: Foo]: number; }

It doesn't seem to fit with the syntax of the rest of the enum body, where names and values are separated with an equals operator.
What I'm about to propose would keep the interior as a simple list, simply expanding the inference a bit. That would also simplify the necessary changes to the parser, becoming more purely additive.
This is still backwards-compatible with the original semantics, including with const enums. The explicit version's type is enforced during creation unlike the implicitly numeric version. Example below (the second would fail to compile):

``` ts
enum Foo {
Bar = 'Bar', // not a string, but checks anyways
}

enum Foo: number {
Bar = 'Bar', // Error: not a string
}
```

A little comparison:

// Current format floating around:
enum TokenTypes {
    [prop: string]: TokenType;

    OpenCurved   = type('(', 1),
    CloseCurved  = type(')', 1),
    OpenBracket  = type('[', 1),
    CloseBracket = type(']', 1),
    OpenCurly    = type('{', 1),
    CloseCurly   = type('}', 1),
    Identifier   = type('Identifier', 0),
    String       = type('String', 0),
    EOF          = type('EOF', 0),
}

// What I'm about to propose:
enum TokenTypes: TokenType {
    OpenCurved   = type('(', 1),
    CloseCurved  = type(')', 1),
    OpenBracket  = type('[', 1),
    CloseBracket = type(']', 1),
    OpenCurly    = type('{', 1),
    CloseCurly   = type('}', 1),
    Identifier   = type('Identifier', 0),
    String       = type('String', 0),
    EOF          = type('EOF', 0),
}

_(And yes, my proposal will allow for any arbitrary type for the enum properties. That's intentional - no need to guess the enum type)_

Proposal for typed enums

These are all amendments to the enum part of the spec.

Enum Declaration

The enum syntax would be extended as follows, where _EnumName_ is the enum's name, _Type_ is the enum's type, and _EnumMembers_ are the members and associated values of the enum type.

_EnumDeclaration:_
enum _EnumName_ { _EnumBody_opt_ }
enum _EnumName_ : _Type_ { _EnumBody_opt_ }

_EnumName:_
_Identifier_

An enum type of the form above is a subtype of _Type_, and implicitly declares a variable of the same name, with its type being an anonymous object containing all the type's names as keys and _Type_ as the value type of each of them. Moreover, if _Type_ is the Number or Symbol primitive types, then the object's signature includes a numeric index signature with the signature [x: number]: string or [x: symbol]: string, respectively. In the first variation, _Type_ is inferred to be the type of the _EnumValue_ of the first _EnumEntry_ of _EnumBody_ if it has an _EnumValue_ (i.e. it's initialized), or the Number primitive type otherwise. In the second variation, _Type_ is explicitly given.

_EnumDeclaration:_
const _EnumBody_opt_ enum _EnumBody_opt_ _EnumName_ _EnumBody_opt_ { _EnumBody_opt_ }
const _EnumBody_opt_ enum _EnumBody_opt_ _EnumName_ _EnumBody_opt_ : _EnumBody_opt_ _PrimitiveEnumType_ _EnumBody_opt_ { _EnumBody_opt_ }

_PrimitiveEnumType:_
boolean
string
number
void

An enum type of the form above is a subtype of _PrimitiveEnumType_. It declares a variable of the same name, with its type being an anonymous object containing all the type's names as keys and _PrimitiveEnumType_ as the value type of each of them. It is said to also be a constant enum type. In the first variation, _Type_ is inferred to be the type of the _EnumValue_ of the first _EnumEntry_ of _EnumBody_ if it has an _EnumValue_ (i.e. it's initialized), or the Number primitive type otherwise. In the second variation, _Type_ is explicitly given. For constant enum types, for the sake of simplicity below, _Type_ references _PrimitiveEnumType_.

The example

enum Color: string { Red, Green, Blue }

declares a subtype of the String primitive type called Color, and introduces a variable 'Color' with a type that corresponds to the declaration

var Color: {
    [x: string]: string;  
    Red: Color;  
    Green: Color;  
    Blue: Color;  
};

The example

enum Color: Type { Red, Green, Blue }

declares a subtype of the type Type called Color, and introduces a variable 'Color' with a type that corresponds to the declaration

var Color: {
    Red: Color;  
    Green: Color;  
    Blue: Color;  
};

Enum Members

Each enum member has an associated value of _Type_ specified by the enum declaration.

_EnumBody:_
_EnumMemberList_ ,__opt_

_EnumMemberList:_
_EnumMember_

_EnumMemberList_ , _EnumMember_

_EnumMember:_
_PropertyName_

_PropertyName_ = _EnumValue_

_EnumValue:_
_AssignmentExpression_

If in an ambient context:

An error occurs if any _EnumMember_ of _EnumMemberList_ has an _EnumValue_.
Skip the rest of this section, as it does not apply.

If _Type_ is explicitly given, an error occurs if a given _EnumValue_ of any _EnumMember_ of _EnumMemberList_ is not of type _Type_.

For each _EnumMember_, if _EnumValue_ is not given, then _EnumValue_ is defined in the first of the following to apply:

If _Type_ is the String primitive type, then let _EnumValue_ be _PropertyName_.
Else, if _Type_ is the Number primitive type, then:
1. If the member is the first in the declaration, then let _EnumValue_ be the primitive number 0.
2. Else, if the previous member's _EnumValue_ can be classified as a constant numeric enum member, then let _EnumValue_ be the _EnumValue_ of the previous member plus one.
3. Else, an error occurs.
Else, if _Type_ is the Symbol primitive type, then let _EnumValue_ be _PropertyName_.
Else, if the constructor for _Type_ accepts a single parameter of the String primitive type, then let _EnumValue_ be a newly constructed instance of _Type_ with a sole argument _PropertyName_.

_Non-normative:_

In other words, _Type_'s constructor must implement

ts interface TypeConstructorWithString { new (value: string): <Type>; }

Else, if the constructor for _Type_ accepts a single parameter of the Number primitive type, then:
1. If the member is the first in the declaration, then let _EnumValue_ be let _EnumValue_ be a newly constructed instance of _Type_ with a sole argument of the primitive number 0.
2. Else, if the previous member's _EnumValue_ is a newly constructed instance of _Type_, and the constructor is called with a sole argument that can be classified as a constant numeric enum member, then let _EnumValue_ be that constructor call's argument plus one.
3. Else, an error occurs.

_Non-normative:_

In other words, _Type_'s constructor must implement

ts interface TypeConstructorWithNumber { new (value: number): <Type>; }

Else, if the constructor for _Type_ accepts zero parameters, then let _EnumValue_ be a newly constructed instance of _Type_, with zero arguments.

_Non-normative:_

In other words, _Type_'s constructor must implement

ts interface TypeConstructorWithString { new (): <Type>; }

Else, an error occurs.

A few examples:

_EnumValue_ for Foo is the number 0.

enum E {
    Foo = 0,
}

_EnumValue_ for Foo is the string "Foo".

enum E: string {
    Foo = "Foo",
}

_EnumValue_ for Foo is a symbol wrapping the string "Foo".

enum E: symbol {
    Foo = Symbol("Foo"),
}

_EnumValue_ for Foo is the number 0.

enum E {
    Foo,
}

_EnumValue_ for Foo is the string "Foo".

enum E: string {
    Foo,
}

_EnumValue_ for Foo is new Type("Foo").

class Type {
    constructor(public value: string);
}

enum E: Type {
    Foo,
}

_EnumValue_ for Foo is new Type().

class Type {
    constructor();
}

enum E: Type {
    Foo,
}

An enum member is classified as follows:

If the member declaration specifies no value, and _Type_ is either the String primitive type or the Number primitive type, the member is considered a constant enum member, inferred according to their member name.
If _Type_ is the Boolean primitive type, and the member declaration specifies a value that can be classified as a constant boolean enum expression (as defined below), the member is considered a constant enum member.
If _Type_ is the Number primitive type, and the member declaration specifies a value that can be classified as a constant numeric enum expression (as defined below), the member is considered a constant enum member.
If _Type_ is the String primitive type, and the member declaration specifies a value that can be classified as a constant string enum expression (as defined below), the member is considered a constant enum member.
If _Type_ is the Void primitive type, and the member declaration specifies a value that can be classified as a constant void enum expression (as defined below), the member is considered a constant enum member.
Otherwise, the member is considered a computed enum member.

A _constant enum expression_ is a constant boolean enum expression, a constant numeric enum expression, a constant void enum expression, or a constant string enum expression.

A _constant boolean enum expression_ is a subset of the expression grammar that can be evaluated fully at compile time, and returns only booleans. A constant boolean enum expression is one of the following:

A boolean literal
An identifier or property access that denotes a previously declared member in the same constant enum declaration, if _Type_ is the Boolean primitive type.
A parenthesized constant boolean enum expression.
A ! unary operator applied to a constant enum expression.

A _constant numeric enum expression_ is a subset of the expression grammar that can be evaluated fully at compile time, and returns only numbers. An expression is considered a constant numeric enum expression if it is one of the following:

A numeric literal.
An identifier or property access that denotes a previously declared member in the same constant enum declaration, if _Type_ is the Number primitive type.
A parenthesized constant numeric enum expression.
A +, –, or ~ unary operator applied to a constant enum expression.
A + operator applied to two constant numeric enum expressions.
A –, *, /, %, <<, >>, >>>, &, ^, or | operator applied to two constant enum expressions.

A _constant string enum expression_ is a subset of the expression grammar that can be evaluated fully at compile time, and returns only strings. An expression is considered a constant numeric enum expression if it is one of the following:

A string literal.
A template string literal whose expressions are all constant enum expressions.
An identifier or property access that denotes a previously declared member in the same constant enum declaration, if _Type_ is the String primitive type.
A parenthesized constant string enum expression.
A + operator applied to two constant enum expressions, one of which is a constant string enum expression.

A _constant void enum expression_ is a subset of the expression grammar that consists of either the primitive null or the primitive undefined.

Proposed emit

Section 9.1 is amended to the following:

var <EnumName>;
(function (<EnumName>) {
    <EnumMemberAssignments>  
})(<EnumName>||(<EnumName>={}));

where _EnumName_ is the name of the enum, and _EnumMemberAssignments_ is a sequence of assignments, one for each enum member, in order they are declared. _EnumMemberAssignments_ is defined in the first applicable section below.

If _Type_ is the Number or Symbol primitive types, let the following be _EnumMemberAssignments_.

js <EnumName>[<EnumName>["<PropertyName>"] = <EnumValue>] = "<PropertyName>";

If _Type_ is of any other type, let the following be _EnumMemberAssignments_.

js <EnumName>["<PropertyName>"] = <Value>;

Examples

For either of these sources,

enum Color { Red, Green, Blue }
enum Color: number { Red, Green, Blue }

the following should be emitted:

var Color;
(function (Color) {
    Color[Color["Red"] = 0] = "Red";
    Color[Color["Green"] = 1] = "Green";
    Color[Color["Blue"] = 2] = "Blue";
})(Color||(Color={}));

For this source,

enum Color: string { Red, Green, Blue }

the following should be emitted:

var Color;
(function (Color) {
    Color["Red"] = "Red";
    Color["Green"] = "Green";
    Color["Blue"] = "Blue";
})(Color||(Color={}));

For this source,

enum Color: symbol { Red, Green, Blue }

the following should be emitted:

var Color;
(function (Color) {
    Color[Color["Red"] = Symbol("Red")] = "Red";
    Color[Color["Green"] = Symbol("Green")] = "Green";
    Color[Color["Blue"] = Symbol("Blue")] = "Blue";
})(Color||(Color={}));

For this source,

class Type {
    constructor(public value: String);
}

enum Color {
  Red = new Type("Red"),
  Green,
  Blue,
}
enum Color: Type { Red, Green, Blue }

the following should be emitted for either version of the Color enum:

var Color;
(function (Color) {
    Color["Red"] = new Type("Red");
    Color["Green"] = new Type("Green");
    Color["Blue"] = new Type("Blue");
})(Color||(Color={}));

For this source,

class Type {
    constructor();
}

enum Color: Type { Red, Green, Blue }