-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Expressions for string-literal types #12861
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
It'd be interesting to hear about more use cases like this so we can better understand the problem space. |
is not that the same as #6579? |
@RyanCavanaugh some more uses cases:
Compile-time concatenation of string literal types would be sufficient to address both of these use cases. |
I agree w/ @mhegazy that the mentioned request and mine are spiritually if not identically similar. The use case is essentially expressions whose range is the type you are attempting to define. I believe that for any candidate value or type instance your expression is statically run against it to determine if it is in the set or not? I may be stating the obvious ( or obviously wrong ? ) but that's how I see them being similar. |
I would say #6579 is more feasible, since anything in the type system needs to be statically analyzable. regexp's have a better chance of being statically analyzable than a full expression level syntax. |
As a step, sure, but having the power of typescript at compilation-time would really be a tremendous boon to flexibility. |
types are used as inference source/target and it becomes hard once you add a dynamic behavior to them. |
TypeScript Version: 2.2
Code
Expected behavior:
Evaluating standard ES6 during compile-time would really open up some expressiveness in defining types like these. This sort of compile-time expression evaluation is spiritually similar to the enum expressions that are available today.
Actual behavior:
The text was updated successfully, but these errors were encountered: