3 ms·

No, I used very few words to try to make it clear that enums in Typescript are syntactic salt. Might look sweet from a distance, but it's doing the wrong thing

No, I used very few words to try to make it clear that enums in Typescript are syntactic salt. Might look sweet from a distance, but it's doing the wrong thing in multiple ways and if you expect it to taste sweet you are in for a surprise. The code generation is ancient and wrong for modern JS. The types are ancient and wrong for modern TS. People do love syntactic sugar. That's why it is important to point out why sometimes it is table salt and they should avoid trying to put it on their desserts.

motorest 2y ago
> No, I used very few words to try to make it clear that enums in Typescript are syntactic salt. They aren't. As others already pointed out, enums greatly simplify some usecases, although they brush the complexity of implementing them under the rug.
- baobun 2y ago
  can you name some use-case it actually would greaty simplify as you say? Because neither TFA nor this thread has yet proposed anything that isnt better served by later introduced (say TS 3~4.x+) language features or even external libraries if you actually do want to use them for their generated runtime library (enums) and not just their type-aspects. I have only seen them complicate things. You could use it to make typescript prevent forking and code-duplication within a codebase of engineers you dont trust, I guess. But it doesn't seem like a great use either. Consider https://news.ycombinator.com/item?id=42772924 https://news.ycombinator.com/item?id=42772924
  - WorldMaker 2y ago
    > You could use it to make typescript prevent forking and code-duplication within a codebase of engineers you dont trust, I guess. But it doesn't seem like a great use either. Right, for that you are better off using unique Symbols. That's definitely the modern JS way to nominally type something in a private way that stays inside your API boundary and is very much more useful because it is also enforced at runtime, too, and not just an accident of old type mechanics.
- WorldMaker 2y ago
  The complexity they brush under the rug is dangerous and has rough edge cases that have caused real damage in applications I and others have worked on. I'm trying to warn these others that think enums "greatly simplify" things that they don't really simplify things, especially by how much they can hurt. The modern alternatives are all just as simple, but far more reliable. Believe me or not, it is still a fair warning that enums aren't the syntactic "sugar" that they appear to be, they aren't as sweet as they look, and you may get a "salty" surprise (apologies if that sounds more vulgar than intended due to slang overloading) if you keep using them. You don't have to trust my warning on it (or any of the others in this and nearby threads), but that doesn't make it not worth making the warning and suggesting alternatives. Yes, I've got eslint errors turned on disallowing any use of enums at this point, because I see it as a code smell/risk, but that doesn't mean I'm going to take away the feature from your codebase, that's up to you and your judgment.

motorest 2y ago

> No, I used very few words to try to make it clear that enums in Typescript are syntactic salt. They aren't. As others already pointed out, enums greatly simplify some usecases, although they brush the complexity of implementing them under the rug.

baobun 2y ago
can you name some use-case it actually would greaty simplify as you say? Because neither TFA nor this thread has yet proposed anything that isnt better served by later introduced (say TS 3~4.x+) language features or even external libraries if you actually do want to use them for their generated runtime library (enums) and not just their type-aspects. I have only seen them complicate things. You could use it to make typescript prevent forking and code-duplication within a codebase of engineers you dont trust, I guess. But it doesn't seem like a great use either. Consider https://news.ycombinator.com/item?id=42772924 https://news.ycombinator.com/item?id=42772924
- WorldMaker 2y ago
  > You could use it to make typescript prevent forking and code-duplication within a codebase of engineers you dont trust, I guess. But it doesn't seem like a great use either. Right, for that you are better off using unique Symbols. That's definitely the modern JS way to nominally type something in a private way that stays inside your API boundary and is very much more useful because it is also enforced at runtime, too, and not just an accident of old type mechanics.
WorldMaker 2y ago
The complexity they brush under the rug is dangerous and has rough edge cases that have caused real damage in applications I and others have worked on. I'm trying to warn these others that think enums "greatly simplify" things that they don't really simplify things, especially by how much they can hurt. The modern alternatives are all just as simple, but far more reliable. Believe me or not, it is still a fair warning that enums aren't the syntactic "sugar" that they appear to be, they aren't as sweet as they look, and you may get a "salty" surprise (apologies if that sounds more vulgar than intended due to slang overloading) if you keep using them. You don't have to trust my warning on it (or any of the others in this and nearby threads), but that doesn't make it not worth making the warning and suggesting alternatives. Yes, I've got eslint errors turned on disallowing any use of enums at this point, because I see it as a code smell/risk, but that doesn't mean I'm going to take away the feature from your codebase, that's up to you and your judgment.