@mhegazy Want to take a look?

@ahejlsberg
Reading the descriptions, I have the impression that the following code example won't be a--noImplicitAny error. Am I wrong?

functionf(x:number[]):void{ ...}letx=[];// x: any[]x.push(3);// x: number[]f(x);// x is ok according to control flow, so no --noImplicitAny error?

Am I wrong?

You are correct. this is not flagged as an implicit any error.

@mhegazy this is not safe, though.
Consider thatf() might use thex value later (through capture or saving into a global variable) and the code might arbitrarily changex.

functionf(x:number[]):void{setImmediate(function(){console.log(x.reduce((a,b)=>a*b,1));});}letx=[];x.push(3);f(x);x.push("I am not a number");// ok, now x: (string|number)[]

Typescript is already unsafe in this way. You can also write

let sns: (string | number)[];f(sns);

Never mind, I was completely wrong. It doesn't work.

@sandersn
Yeah, I like that this enables more errors to be caught when migrating (untyped) JS code.
I like that you now can drop more type declarations for local variables as long as you use them correctly.

But I think many people like TS for being (for the most part) statically type-safe and usenoImplicitAny to guarantee that no dynamically typed code slips through, i.e.as a way to enforce type safety.
Currently, this PR weakens the guarantees provided bynoImplicitAny and allows some unsafe code that was not possible before.

Thus, I would suggest that you limit what is allowed by this feature or (harder) only allow cases that are provably correct (e.g. determine that the dynamic type never changes to an incompatible type).

I can at least imagine the following operations to be potentially unsafe: saving the value in an object, an array or a variable in an outer scope; assigning the value to a setter; passing the value to a function; capturing the value in a closure; calling a member of the value;new-ing the value.

@jods4, the compiler today does not guard against side effects in multiple places. it is not specific to noImplicitAny checks. for instance:

functionf(x:{a:number}){setTimeout(()=>{x.a.toFixed();},10);}varx:{kind:"number",a:number}|{kind:"string",a:string};if(x.kind==="number"){f(x);}x.a="string";// potentially unsafe, as x has already been captured.

Arrays are just like objects with properties when it comes to narrowing. I do understand your concern, but really this issue is a general design limitation and not specific to this change.

@mhegazy
Yes, I agree.
That's why I said TS isfor the most part statically type-safe, which is already a lot 😃

That said, having safety holes doesn't necessarily mean we should add new ones. I guess the question is: do benefits outweight the drawbacks?

Your example is a lot more convoluted than the simple example I gave, which was just:

letx=[];x.push(3);f(x);x.push("NaN");

I guess what annoys me most here is that this is unsafe because I usex in a dynamic way, without declaring my intent, undernoImplicitAny. I think the essence ofnoImplicitAny is to forbid errors from unwanted dynamic code.

My opinion:

1. This is great for migrating existing JS code andI wouldn't change anything in this context.
2. I believe people who usenoImplicitAny have little use for that feature. Typically those people want maximum safety and try to have everything typed. In this context and with all the inference we already have, you seldom have the need for this shortcut. In my company we build web apps exclusively in this model and I can't say I ever had feature envy for that.

To maximize both safety and value,I would suggest that undernoImplicitAny, the dynamic type of locals cannot be changed. I.e.:

letx;// this is not an error yet.x=4;// so x: number at this pointconsole.log(x.toFixed());// surex+=5;// and so on...lety;// same thingy=4;// so y: numbery="Four";// still an error when --noImplicitAny. Can't use dynamic types without explicit declaration.