Repository navigation
Suggestion - Obtaining property type with dot notation on index type #30815
Description
Search Terms
dot notation, index type
Suggestion
Enable accessing object property type in the type domain, when possible
type Obj = {
x: number;
y: number;
}
type X = Obj['x'];
// This would be an error, but it's a much more concise/intuitive syntax
type X2 = Obj.x;
Note this is not the same as #12596, which is a breaking change.
I'm only suggesting allowing Obj.propertyName to be a type,
or as an alias of Obj['propertyName'].
propertyName must have been known to the compiler, as in the old index type.
One possible drawback is it might cause confusion with accessing objects,
but not that much since when reading TS code, people tend to first look
at which part is the typing and which part is the runtime.
Use Cases
This applies to all cases where index type is used without mapped types.
It would improve the readability and reduce a lot of syntax noise.
Examples
Shamelessly copied the code from #17588, and image how this code will look better
with the new syntax :)
Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.
Activity
jcalz commentedon Apr 8, 2019
This would still be a breaking change, in that this notation conflicts with types inside namespaces or modules:
zen0wu commentedon Apr 8, 2019
That's good call. Makes sense.
I was 70% sure there was a reason for not doing this, just failed to find it out via searching. If sharing namespace and local interface/types are a common practice, then we should probably close this.
On the other hand, looks to me that defining a type name starting a lower-case letter is a bad practice already. So maybe practically they shouldn't conflict :)
Veetaha commentedon Apr 8, 2019
I agree with shivawu there is no need to tolerate such (IMHO) bad practices (having same namespace name and type name in the common lexical scope). Yes, it does is a breaking change, though you may workaround this by creating an alias for the type or namespace, but it doesn't imply that we must drop this proposal. I think that this syntax is more intuitive and concise than indexing with a string literal. When I started with TypeScript I always wanted to extract a property type from some interface with the "dotname" notation and always disappointed when this didn't work.
RyanCavanaugh commentedon Apr 9, 2019
Multiple meanings of the same name are actually pretty common when you import a module, e.g.
The real stickler here is a multiply-dotted name, e.g.
k.a.b.c.d.ecould refer to up to 16 different entities. Name resolution really needs to be unambiguous.zen0wu commentedon Apr 9, 2019
Thanks for explaining! On a side note I would guess the issue was name resolution happens before type checking, so probably at the time of resolution, we don't have the info of "what is this name's, a type, or a module, or something else". Not sure if that's right though :)