GeezerVison

Also probably solves #7722.

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

and how about index signatures?

interface A {
  foo: string;
  [property: string]: any;
}

what will be keysof A look like? string ?

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

When this going to landed?

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

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

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.

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.

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.

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.

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:

class X {
  constructor(private name: string) {}
}

let x = new X("Godfrey");
x['name'] // type checks, "Godfrey", type is string, as expected
x['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:

class X {
  constructor(private name: string) {}
}

let x = new X("Godfrey");
x['name'] // type checks, value is "Godfrey", type is string, as expected
x['nmae'] // type checks, value is undefined, type is any, unexpected

function get<T, K extends keysof T>(obj: T, key: K) {
  return obj[key];
}

let x = new X("Godfrey");
get(x, 'name') // type checks, "Godfrey", type is string (?), as expected
get(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.

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.

Closing as this has been superseded by #11929.