GeezerVison

Mohamed Hegazy (@mhegazy) Want to take a look?

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

function f(x: number[]): void { ... }

let x = [];  // 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.

Mohamed Hegazy (@mhegazy) this is not safe, though.
Consider that f() might use the x value later (through capture or saving into a global variable) and the code might arbitrarily change x.

function f(x: number[]): void {
  setImmediate(function () { 
    console.log(x.reduce((a, b) => a * b, 1));
  });
}

let x = [];
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.

Nathan Shively-Sanders (@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 use noImplicitAny 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 by noImplicitAny 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.

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

function f(x: { a: number }) {
    setTimeout(() => {
        x.a.toFixed();
    }, 10);
 }

var x: { 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.

Mohamed Hegazy (@mhegazy)
Yes, I agree.
That's why I said TS is for 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:

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

I guess what annoys me most here is that this is unsafe because I use x in a dynamic way, without declaring my intent, under noImplicitAny. I think the essence of noImplicitAny is to forbid errors from unwanted dynamic code.

My opinion:

1. This is great for migrating existing JS code and I wouldn't change anything in this context.
2. I believe people who use noImplicitAny 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 under noImplicitAny, the dynamic type of locals cannot be changed. I.e.:

let x;  // this is not an error yet.
x = 4;  // so x: number at this point
console.log(x.toFixed());  // sure
x += 5;  // and so on...

let y;  // same thing
y = 4;  // so y: number
y = "Four";  // still an error when --noImplicitAny. Can't use dynamic types without explicit declaration.