For var in object: Var is implicitly any without error

[M-Pixel]

In the following statement,

for (let subscription in this._subscriptions) {
    // Do something with subscription
}

The variable subscription is considered type any. Although I'm compiling with noImplicitAny as true, no error is given. Based on the for spec, it seems as if subscription should implicitly be considered string.

Because of this, it's possible to compile with typo functions that will cause errors at runtime.

[DanielRosenwasser]

#3500 is partially related.

[M-Pixel]

It is! From that thread, it sounds like keys can be number | sybmol | string, but specifying this would still allow more intelligent autocomplete and warnings.

[mhegazy]

for the record, this will be a breaking change.

[drake7707]

This might be beside the point but shouldn't the correct code in this case be :

for (let subscription OF this._subscriptions) {
    // Do something with subscription
}

with 'of' instead of 'in'?

[M-Pixel]

No, because of is for iterating arrays, while in is for iterating objects (in most cases, objects being utilized as maps).

In the case of of, the var is implicitly the type specified in the Array type parameter. I do believe that works correctly already.

[JirkaDellOro]

Yes, #3500 is related but unfortunately it has been closed! I'd appreciate discussing this further. There are some aspects in the last post that was written almost two months ago, that may be worth thinking about. This thread #4518 is yet another point for allowing the explicit any...

[jeffreymorlan]

My understanding of ES6 is that for/in iteration should only ever yield strings, not number or symbol. Numbers are returned as strings, and symbols are omitted entirely. So there is no need to use a union type.

For/in iteration is defined in terms of the [[Enumerate]] internal method, which in turn is defined (for non-Proxy objects) in 9.1.11:

When the [[Enumerate]] internal method of O is called the following steps are taken: Return an Iterator object (25.1.1.2) whose next method iterates over all the String-valued keys of enumerable properties of O. [emphasis mine]

As far as I can tell, the only way to get for/in to return non-strings is to be intentionally evil by creating a Proxy with an Enumerate handler that returns non-string values.

As an experiment I tried changing tsc to make for/in variables stringType instead of anyType, and checked a large codebase - two errors were added, both of which indicated actual bugs (string compared to number with ===).

[vladima]

that is the good point. informal definition here only returns keys of type string. @bterlson can you please confirm that our reading of the spec is correct and the for/in can only yield strings?

[JirkaDellOro]

Whatever the outcome of this, please make sure that the explicit annotation is allowed in those loops and the catch statement for consistency! Even if it stays with 'any'...