Suggestion - Obtaining property type with dot notation on index type

[zen0wu]

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 :)

CODE

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.

[jcalz]

This would still be a breaking change, in that this notation conflicts with types inside namespaces or modules:

declare interface Foo {
    bar: number;
}
declare namespace Foo {
    type bar = string;
}
type FooBar = Foo['bar']; // number
type FUBAR = Foo.bar; // string

[zen0wu]

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]

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]

Multiple meanings of the same name are actually pretty common when you import a module, e.g.

import k from './k';

const t1: k.g = ...; // g means what?

The real stickler here is a multiply-dotted name, e.g. k.a.b.c.d.e could refer to up to 16 different entities. Name resolution really needs to be unambiguous.

[zen0wu]

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 :)