This project is read-only.


Suggestion for enums


It would be great if enums still acted as numbers for arithmetic and bitwise operators, but could also be toString'ed correctly.

That could be done by creating a class for an enum, and overriding valueOf and toString.

Also the name of an enum should be possible to use as a converter function from number to the enum (similar to Number("12")).

Creating classes for enums might sound non-performant, but actually there could only be a small number of values per enum.
Closed Jul 28, 2014 at 11: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:


MgSam wrote Jan 30, 2013 at 4:28 PM

I think the concept of enums should be expanded beyond C#'s crappy implementation of them.

Enums are conceptually a group of related constants. They should be able to take values of any type, not just integers. This is how they work in Java and it is much nicer than the C# equivalent.

It would also be nice if they supported their own methods (as they do in Java).

Also, since they should support any type, to get the underlying value I think you'd call a .value() method or something similar (rather than a cast, which requires the user has to explicitly specify the value type)

In addition, right now, type safety is not enforced on enums. This needs to be fixed. I can do this:
enum Dog{

var a: Dog = 5;

stanthomas wrote Mar 21, 2013 at 5:44 PM

An enum is commonly understood to be a set of distinct values that can be assumed by a variable of that type. Conceptually, the underlying representation of the values is an internal implementation detail. The values form a sequence so one can be incremented to another and greater than another. Use to index arrays is natural and desirable. The underlying implementation as labels for a sequence of integer values is often exposed but not strictly necessary. (What you proposed is a collection, not an enum.)

You could see
enum color {red, blue, green};          // note no association with underlying value
as syntactic sugar for
#define red 0
#define blue 1
#define green 2
and I would be perfectly happy if TypeScript were to implement enums in this way, writing the underlying integer into the generated javascript.
But it would be nice if some additional compile time features and checks were added, e.g.
enum color {red, blue, green};;               // error

var background: color =;   // ok
background = 5;                       // error
background = 0;                       // ideally an error too

var b: bool = ==;     // will be true
b = >;                  // will be true
b = > 0;                          // ideally an error but could be
                                             // undefined behaviour;                               // is undefined

var pallette: string[color] = [];        // a fixed size array accepting index values
                                         // from the color enum
pallette[] = '#ff0000';         // ok
pallette[5] = 'five';                    // error
and the behaviour of javascript functions, toString() etc., is undefined but probably use the underlying integer