Keysof type operator

[Wesley Wigham (weswigham)]

Fixes half of #1295. (Honestly, that issue is like proposals for three separate but interoperating features) The remaining parts of #1295 are what I call a "type access expression" - a mirror of element access expressions, but for types (quite literally the same logic) - and altering index resolution logic to, rather than using unions to check for index signature compatibility, be able to use a union of string literals to create a union of the types of those members.

The part that this PR addresses is an operator for finding all of the keys of an arbitrary type. This PR adds a new "type operator" (akin to typeof) - keysof. Used like so:

interfaceItem<T>{owner: Person;id: number;contents: T}letx: keysofItem<any>;x="id";// validx="owner"// validx="content"// error! "content" not assignable to keysof Item<any>interfaceHelloWorld{hello: any;world: any;}functioncheck<KextendskeysofHelloWorld>(key: K): K{returnkey;}// 'y' has type '"hello"'lety=check("hello");check("hullo");// error! "hullo" not assignable to keysof HelloWorld

A parameter or return type being a keysof type causes it to be contextually types as a string literal if need be. A keysof type resolves to a union of the string literal types of the keys of the given type when it is actually resolved (which it is resolved to for relationship checking). It is StringLike, and as such it has the apparent type of a string. It is effectively sugar for writing out the union type of all the keys of an object by hand, except it is also able to be generically instantiated.

cc Daniel Rosenwasser (@DanielRosenwasser)

[Ali Taheri Moghaddar (alitaheri)]

Also probably solves #7722.

How would classes and namespaces work with this? ( if they should in the first place 😅 )

and how about index signatures?

interfaceA{
foo: string;[property: string]: any;}

what will be keysof A look like? string ?

[Wesley Wigham (weswigham)]

Ali Taheri Moghaddar (@alitaheri): keysof ClassName gets you the instance members, keysof typeof ClassName gets you the static members, no special handling required. Any ole' type is supported in the argument position (with the caveat that anonymous objects must be within parenthesis to disambiguate them from function bodies).

[Daniel Rosenwasser (DanielRosenwasser)]

Can you split this into intermediate variables?

[Alex (wclr)]

When this going to landed?

[Daniel Rosenwasser (DanielRosenwasser)]

Renamed in favour of (@whitecolor) We need to discuss this at a design meeting. There are small details that can make all the difference (such as what to do with index signatures).

[Alex (wclr)]

Daniel Rosenwasser (@DanielRosenwasser) it would be cool if another part for #1295 would be implemented soon

[Aluan Haddad (aluanhaddad)]

I think this is a big step forward for the type system. The question I have, and sorry if this has already been answered, is this: What is the enumeration algorithm used?

1. Is it the same as Object.keys?
2. Is it the same as an unfiltered for..in?
3. If neither of the above, how exactly does it work.

On the one hand, it could be very surprising to not get the property keys of super class properties, especially as subclassing becomes more and more fashionable. On the other, it would be equally surprising if it behaved differently from Object.{keys | entries | values}.

Personally, I would prefer it to only return enumerable own properties, but I almost never create class hierarchies in TypeScript.

[Daniel Rosenwasser (DanielRosenwasser)]

Aluan Haddad (@aluanhaddad) Problem is that enumerable own properties aren't encoded in the type system and there's not really a straightforward way we've thought of to add it. Nathan Shively-Sanders (@sandersn) ran into similar issues with the object rest & spread operators.

[Aluan Haddad (aluanhaddad)]

Daniel Rosenwasser (@DanielRosenwasser) thank you for clarifying.

It makes a lot of sense that the language does not track own properties because statically modelling the flexibility of JavaScript's composition mechanisms would seem to preclude doing so.

Perhaps if this operator walks the prototype chain a different name would be appropriate.

keysof is a really pleasant name, but if you read it aloud in a mathematical style it, sounds like calling Object.keys. I don't mean to be pedantic here, but it would be confusing if you use the latter frequently.

[Remo H. Jansen (remojansen)]

I created #11813 because I was not aware of this. I have closed it but it can still be used as a real world use case for the need of this operator.

[Yehuda Katz (wycats)]

Aluan Haddad (@aluanhaddad) I can understand why you expect keysof and Object.keys to refer to the same concept (they both have the word "keys" in them, after all).

That said, I'd find it unfortunate if this very useful operator was restricted to enumerable-own properties.

Here's an example scenario I ran into today that got me thinking about this feature again: creating a hard-fail version of the index-for-friendly-access trick:

classX{constructor(privatename: string){}}letx=newX("Godfrey");x['name']// type checks, "Godfrey", type is string, as expectedx['nmae']// type checks, undefined, type is any, unexpected

In other words, this trick conflates the elimination of privacy checks with a willingness to accept successful type-checking and any as a result if the property doesn't exist at all.

We could use the keysof operator to create a safer version of the same operator:

classX{constructor(privatename: string){}}letx=newX("Godfrey");x['name']// type checks, value is "Godfrey", type is string, as expectedx['nmae']// type checks, value is undefined, type is any, unexpectedfunctionget<T,KextendskeysofT>(obj: T,key: K){returnobj[key];}letx=newX("Godfrey");get(x,'name')// type checks, "Godfrey", type is string (?), as expectedget(x,'nmae')// fails to type check

Whether this works or not depends on whether keysof includes private or protected fields, and whether the type inferencer expands get correctly.

Regardless of those details, this illustrates that there may be valid use-cases for keysof working both against private/protected fields, against, non-enumerable fields, and against non-own fields.

My own perspective is that keysof should match the semantics of the no-implicit-any indexing operator: in other words, a key is in keysof (typeof val) if typeof val[key] is a type known to the type system. Pairing a keysof type check with the indexing operator seems eminently reasonable to me.

This might also argue for a few flavors of keysof, but matching semantics already encoded in the type system in some way seems like a pre-requisite for quick inclusion.

Finally, I also wonder whether not encoding enumerable/own in the type system will be practical in the long-term, especially considering the soon-to-be-included object-spread ({ ...a, ...b }) operator in JavaScript.

[Aluan Haddad (aluanhaddad)]

Yehuda Katz (@wycats) I think you're points about overall usefulness outweigh my arguments about consistency with existing features. While I don't use classes particularly often I do find the object-spread example very compelling. In light of that feature, requiring ownness would kill a lot of the usefulness even in scenarios involving simple object literals. Also if manifest mixin support is ever added to ECMAScript, restricting it to enumerable own properties would also be very unfortunate.

I am convinced.

[Anders Hejlsberg (ahejlsberg)]

Closing as this has been superseded by #11929.