You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently (as of TypeScript 0.9), TypeScript supports overloading on constants, but string constants only.
This seems like a slightly arbitrary restriction, although I do agree that strings are the most obvious case where this is necessary. I do think there is (at least) one more case that comes up frequently though: booleans.
This takes a boolean 2nd argument; a flag which changes the behaviour of the method slightly. If true, it recursively flattens, and if false it only flattens a single level.
Lodash also has _.flatten / _.flattenDeep methods without boolean arguments that follow each of these behaviours respectively without the flag. While I think we can agree that generally using the different methods where possible is often better, this still gets a lot of use, and boolean flags for this sort of thing are pretty common generally.
Notably, these two (recursive/non-recursive) behaviours do have different type signatures, as you can see in the DefinitelyTyped definitions of all three different methods (https://github.com/borisyankov/DefinitelyTyped/blob/master/lodash/lodash.d.ts#L848-L881). The method with the boolean signature though has to be overly general to cover both cases, even though when the flag passed is constant we can easily be more specific at compile time.
This would be covered more generally by 'singleton types', which have been discussed for strings on #1003, and for booleans on #2873 (comment).
Singleton types (at least for strings so far) have been approved according to #2936 but things have gone quiet about the concept for a quite a while, and they are not in the roadmap. Would be nice to get an update from someone on the team about where this is at.
Currently (as of TypeScript 0.9), TypeScript supports overloading on constants, but string constants only.
This seems like a slightly arbitrary restriction, although I do agree that strings are the most obvious case where this is necessary. I do think there is (at least) one more case that comes up frequently though: booleans.
Motivation
My current motiviating example for this is in Lodash's _.flatten function: https://lodash.com/docs#flatten
This takes a boolean 2nd argument; a flag which changes the behaviour of the method slightly. If true, it recursively flattens, and if false it only flattens a single level.
Lodash also has _.flatten / _.flattenDeep methods without boolean arguments that follow each of these behaviours respectively without the flag. While I think we can agree that generally using the different methods where possible is often better, this still gets a lot of use, and boolean flags for this sort of thing are pretty common generally.
Notably, these two (recursive/non-recursive) behaviours do have different type signatures, as you can see in the DefinitelyTyped definitions of all three different methods (https://github.com/borisyankov/DefinitelyTyped/blob/master/lodash/lodash.d.ts#L848-L881). The method with the boolean signature though has to be overly general to cover both cases, even though when the flag passed is constant we can easily be more specific at compile time.
Design
Exactly the same as for string constants (https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#3.9.2.4), but with true/false values.
See below for examples:
The text was updated successfully, but these errors were encountered: