Skip to content
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

Expressions for string-literal types #12861

Closed
stevekane opened this issue Dec 12, 2016 · 7 comments
Closed

Expressions for string-literal types #12861

stevekane opened this issue Dec 12, 2016 · 7 comments
Labels
Duplicate An existing issue was already created Suggestion An idea for TypeScript

Comments

@stevekane
Copy link

stevekane commented Dec 12, 2016

TypeScript Version: 2.2

Code

/*
 We need to create enumerated literal types for this domain that look like the following:
 semantic: 'POSITION_1'
 semantic: 'NORMAL_32'
 semantic: 'TEXCOORD_6'

 it would be nice to capture these string literals via type-level expressions at compile-time.
*/
// current approach
type Semantic
  = 'POSITION_0'
  | 'POSITION_1',
  // ...
  | 'NORMAL_0',
  // ...

// proposed shorthand via type-level compile-time expressions
type Semantic
  = 'POSITION_' + ( '1' | '2' | '3' | '4' )
  | 'NORMAL_' + ( '1' | '2' | '3' | '4' )

// "final-form" ?
type Semantic
  = [ ...Array(10).keys() ].map(k => 'POSITION_' + k)
  = [ ...Array(10).keys() ].map(k => 'NORMAL_' + k)

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:

@RyanCavanaugh RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Dec 12, 2016
@RyanCavanaugh
Copy link
Member

It'd be interesting to hear about more use cases like this so we can better understand the problem space.

@mhegazy
Copy link
Contributor

mhegazy commented Dec 12, 2016

is not that the same as #6579?

@yortus
Copy link
Contributor

yortus commented Dec 13, 2016

@RyanCavanaugh some more uses cases:

Compile-time concatenation of string literal types would be sufficient to address both of these use cases.

@stevekane
Copy link
Author

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.

@mhegazy mhegazy added Duplicate An existing issue was already created and removed Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature labels Dec 13, 2016
@mhegazy
Copy link
Contributor

mhegazy commented Dec 13, 2016

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.

@stevekane
Copy link
Author

As a step, sure, but having the power of typescript at compilation-time would really be a tremendous boon to flexibility.

@mhegazy
Copy link
Contributor

mhegazy commented Dec 13, 2016

types are used as inference source/target and it becomes hard once you add a dynamic behavior to them.

@mhegazy mhegazy closed this as completed Apr 21, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants