enum shorthand
enum value shorthand
enum accessor shorthand
It would be nice to not have to type out a full enum name in contexts where a value of that enum is required, like in Swift.
Sometimes enumerations need long names for clarity, or exist in namespaces. If you have to use an enum with a long name in a lot of places, it becomes cumbersome very quickly. Omitting the enum name also makes usage much more readable in situations where the enum is obvious. This would also make enum autocomplete even more trivial for VSCode users because they need not search for the enum and just start typing with a . and the auto-import/autocomplete takes care of the rest.
I will first show the real use case that led me to create this issue, and then a more likely scenario. My personal use case was mapping general data column definitions to definitions for AngularJS UI-Grid as well as CSV and Excel columns for data export.
export const enum ColumnAvailability {
UiGrid = 1 << 0,
Excel = 1 << 1,
CSV = 1 << 2
}
export interface Column {
// ...data fields...
/**
* Bitset of contexts where this column definition is
* relevant and needs to be included.
*/
availability: number;
}
let columns: Column[] = [{
availability: ColumnAvailability.UiGrid | ColumnAvailability.Excel
}, {
availability: ColumnAvailability.UiGrid
}, {
availability: ColumnAvailability.Excel | ColumnAvailability.CSV
}, {
availability: ColumnAvailability.UiGrid | ColumnAvailability.Excel | ColumnAvailability.CSV
}];
let muchNicer: Column[] = [{
availability: .UiGrid | .Excel
}, {
availability: .UiGrid
}, {
availability: .Excel | .CSV
}, {
availability: .UiGrid | .Excel | .CSV
}];
Here is an example with a namespaced enum. Note that this is not actual Socket.IO usage--websockets and status codes were the first thing that came to mind when brainstorming another example.
import socketio from "socket.io";
declare let mySocket: socketio.Socket;
// without shorthand
mySocket.onclose = event => {
switch (event.statusCode) {
case socketio.StatusCode.Normal:
case socketio.StatusCode.GoingAway:
case socketio.StatusCode.MessageTooBig:
case socketio.StatusCode.InternalError:
case socketio.StatusCode.ServiceRestart:
default:
}
};
// with shorthand :^)
mySocket.onclose = event => {
switch (event.statusCode) {
case .Normal:
case .GoingAway:
case .MessageTooBig:
case .InternalError:
case .ServiceRestart:
default:
}
};
I'm sure many people can appreciate the value in not writing 20-30 extra characters in every line of an enum switch statement, or not having to break up a massive bitwise statement to multiple lines because an enum is used for bitset values.
My suggestion meets these guidelines:
This is most likely out of scope because it requires changing the generated JS. You can get around typing so much by aliasing the enum though:
const _ = socketio.StatusCode;
switch (event.statusCode) {
case _.Normal:
case _.GoingAway:
case _.MessageTooBig:
case _.InternalError:
case _.ServiceRestart:
default:
}
This could be implemented without emitting different JS based on the types of the expressions
Seems this box got unintentionally checked
@AlCalzone Can you please lead me to understand why this feature would require changing emitted code? I'm assuming it's only a syntax sugar and shall not affect the emitted code. In other words, it's just like we programmers are asking the compiler a favor to insert the repeatitive part of the enum for us, nothing more.
Thanks in advance.
@Nandiin It requires changes to emitted code because you use in the switch a statement that would not be valid JS ( case .Normal:). Typescript avoids adding such changes to the JS language, there are just a few examples of this throughout the language which are absolutely necessary (such as type annotations and type assertions). Typescript prefers instead to add type checking to standard JS syntax (current syntax or standard proposed syntax, although enum in general might be a glaring exception to what I just stated)
It seems likely that if enum were suggested today and wasn't added in TypeScript's early days, it would also be dismissed as out of scope. But if enums are going to exist in the language, it seems this is a massive quality of life improvement?
Most helpful comment
It seems likely that if enum were suggested today and wasn't added in TypeScript's early days, it would also be dismissed as out of scope. But if enums are going to exist in the language, it seems this is a massive quality of life improvement?