Compiler should allow assignment of new property in empty object

[yuit]

TypeScript Version: built from master

Code

var range;
range = {} 
range.newProp = 10;  // error

var obj;
obj = {
   propx: 10
}
obj.propy = 20;  // error

Expected behavior:
No error here range.newProp = 10; or obj.propy = 20;

Actual behavior:
Error TS2339 Property 'newProp' does not exist .... or Property 'propy' does not exist ...

[yortus]

Would this change stop the compiler from identifying typos? e.g. what if obj.propy is a typo?

What would the rules be for when a new property can be added, and when the 'property X does not exist' error would still be raised?

[RyanCavanaugh]

• For unannotated uninitialized (or initialized with null/undefined/empty arr/obj) variables
  • Keep this an error under NIA
• Without NIA, keep these as implicit any

[ahejlsberg]

We infer an implicit any type for let and var declarations of the following forms:

let x;
let y = null;
let z = undefined;

With #11263 we introduced control flow analysis for such implicit any variables. That's generally a good thing and certainly will detect issues that we previous didn't find, but it is technically a breaking change. For example:

let x;
x = {};
x.foo = 42;  // Error, {} has no 'foo' property

The code above used to compile because x had type any and nothing was checked. We now control flow analyze the type of x, and following the {} assignment we know that x has no foo property. We may at some point attempt to evolve the type of x when the detect this initialization pattern, but that is out of scope for 2.1.

Some older code bases that compile without --noImplicitAny rely on the loose behavior and currently require an explicit any annotation to be added before they'll compile with 2.1. If we think this is an acceptable break, we can leave things as they are.

Alternatively, we could revert back to the old behavior when --noImplicitAny is disabled (the default state), and only perform control flow analysis when --noImplicitAny is enabled. The reasoning here is that the above pattern is already an error with --noImplicitAny so nothing breaks if we start being stricter.

I'm curious what people think? I'm personally on the fence here.

[mhegazy]

One thing to note is for JS files the new behavior is more desirable. so either ways, we should keep it working in JS files.

[aluanhaddad]

As someone who generally avoids --noImplicitAny I think the new behavior is preferable. I would rather have the advantage of the evolving type analysis without having to enable the flag, even if it required me to place a few more any annotations in my code.