request: optionally disable enum/number implicit conversion

[Spongman]

now that we have union types, can we please have an option to disable the enum/number implicit casts?

I'd really like the following to give me an error:

enum Shape { Circle, Square, Pentagon, Pyramid }
var f = Math.sin(Shape.Square)

[mhegazy]

This breaks flag enums, where bit operations are allowed.

[Spongman]

actually, you could still allow boolean operations on enums. i'm just requesting that they not be implicitly converted to/from numbers (except maybe from zero).

we already have a way of representing collections of constant integers in the language (ie. classes with public static readonly fields). allowing enums to be implicitly converted to/from number just duplicates this and doesn't provide the most useful purpose that enumerations could have - type safety.

[mhegazy]

if we were to do it allover again, i would have flags and enums be separate entities. but that is not possible now. any changes to the enums now would lead to a massive breaking change. The TS code base for instance relies on flags extensively, and i am sure we are not unique in this regard.

[Spongman]

yeah, like i said. can we have an option to do this?

[mhegazy]

we have a limited budget of options, each option adds maintenance costs on the team and learning cost on users.
Moreover we have no other alternatives for flag enums, and we have no plans on adding a new kind of enums.

[Spongman]

well, if what you want is a collection of integer values, then the language already has a non-type-safe alternative: classes. eg:

class MyConsts {
    static readonly Flag1 = (1<<0);
    static readonly Flag2 = (1<<1);
    // etc...
}

this performs almost as well as an enum and it's already non-type-safe. so, basically, what you have today is two almost identical ways of doing exactly the same thing.

as far as i know, since the beginning, Anders has always sold typescript on the grounds that it's a typesafe javascript, useful for building large projects with large teams. adding type safety to enums would certainly fit this goal. i'm pretty sure it would help fix more bugs than would simply providing some syntactic sugar for collections of consts.

[Spongman]

on a related note, i just discovered that you can't have an enum as an object index:

enum Foos {
   Bar = 0,
   Goo = 1,
}

type MAP = { [key: Foos]: number };

results in An index signature parameter type must be 'string' or 'number'

so which is it? is enum a convenient alias for collections of consts numbers, or a typesafe enumeration of discrete elements? 'cos right now it seems inconsistent.

[mhegazy]

see #2049

[Spongman]

hah, so i wrote a tslint rule to do this, and after running on the tsc project i see now why you wouldn't want to do this.

here's my favorite:

namespace ts.formatting {
    const enum Constants {
        Unknown = -1
    }
}

that's an enumeration of all the values that a variable of type Constants can take. really?

why not just this? :

namespace ts.formatting.Constants {
    const Unknown = -1;
}

same for CharacterCodes, ExitStatus & RulesPosition.

[mhegazy]

this one specifically is wrong, but the general rule stands. look at things like NodeFlags.

[Spongman]

absolutely. and nowhere[*] is a variable of type NodeFlags used in a (non-comma) binary or conditional expression with a number-typed expression, or initialized (as a parameter, property or variable) as a number-typed expression, or returned from a number-typed function.

[*] except for a few times where it's compared to 0, which could (arguably should?) be fixed to NodeFlags.None.

indeed, here's a complete diff of changes that would satisfy this: tsc.patch.txt

(also, this: return pos += 2, token = SyntaxKind.ExclamationEqualsToken; ?!)

[michael-s-crouch]

I would also like the ability to check for this. I defined enums entirely so that I could use static typechecking to make sure that they were being used correctly; right now, typescript isn't capturing that.

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.