Typescript types checking

Question 1

let a;
a = 5;
a = "hi";

Why this is valid TypeScript code? Are there any settings to stricter that besides «a:number»? If not, then what's the point of using TypeScipt, if you can use JavaScript + vscode //@ts-check? My tsconfig.json:

"compilerOptions": {
 "baseUrl": ".",
 "outDir": "build/dist",
 "module": "esnext",
 "target": "es6",
 "lib": ["es6", "dom"],
 "sourceMap": true,
 "allowJs": false,
 "strict": true,
 "jsx": "react",
 "moduleResolution": "node",
 "rootDir": "src",
 "forceConsistentCasingInFileNames": true,
 "noImplicitReturns": true,
 "noImplicitThis": true,
 "noImplicitAny": true,
 "strictNullChecks": true,
 "suppressImplicitAnyIndexErrors": true,
 "noUnusedLocals": true
},

Question 2

That is completly weird, i agree... it is being infeered as as Any, but you have noImplicityAny...

Question 3

Can I ask how typescript is supposed to know it is a number or string? shouldn't you be declaring it to be a number so you do not run into it? let a: number

Question 4

@epascarello in my opinion there should be error=warning like «a has any type»

Question 5

The compiler knows through static flow analisys. After the last line, the variable is always a string underneath, even if it disguised as any

Question 6

It works because noImplicitAny does not affect variable declarations. If a variable is declared, but it's type is not declared, it is assumed any.

This was defined like that, because the compiler, despite the variable being any implicitly, can in fact determine its type at every point.

In fact, if you do this:

var a;
a = 5;
a.dot(); // error, number does not have a 'dot' property.
a = "hi";
a.foo(); // error, string does not have a 'foo' property.

You get an error, indicating that string has no property foo, or number has no property dot.

But, if you write:

function(b) {
 return b + 2;
}

This function, however, indicates an error because there is nothing that hints the compiler about what type b holds.

Question 7

When did this change? Presumably with better flow analysis? I can remember getting "implicit any" errors for variables and can even get them when using typescript 1.8. For typescript 2.8 and the same code, there is no error as described here.

Question 8

I guess i found it: improved any inference, typescript 2.1.

Question 9

Yes. It changed around 2.1 or so. There was a PR about this. If the type can be determined by flow analisys, then there is not really an implicit any, even i f the variable can take any value of any type. As long as the type can be determined for every line of code in whuch it appears, there won't be an error.

Question 10

Why this is valid TypeScript code?

To allow backwards compability with javascript. This is completely valid js, so it needs to be valid typescript too. But you can easily opt in typechecking:

let a: number;

Question 11

By the way I cant understand typescript philosophy here. There are almost no differences between TypeScript types checking and raw js with //@ts-checking in VSCode

Question 12

That would be true, if the OP didn't have notImplicitAny turned on. notImplicitAny increases the type safety of your code, but diminishes the compatibility with the existing codebase

Question 13

@foxPro well there are interfaces and enums, and the typechecking goes far beyond these simple cases

Question 14

@OscarPaz you are right, but the notImplicitAny affects function arguments and not variables.

Question 15

Why this is valid TypeScript code?

noImplicityAny only affects "arguments" not "variables".

Consequently this codes is correct:

let a;
a = 'test';
a = 123;

But you will get an error, when you want to declare a functions argument:

function log(someArg) { // Error : someArg has an implicit `any` type
 console.log(someArg);
}

This code would work:

function log(someArg: any | string | number) { // Error : someArg has an implicit `any` type
 console.log(someArg);
}

TypeScript ensures, that you can use types and validates them, when the variable is in use (eg. as an argument).

Here you can find the article.

Oscar Paz 18.3k3 gold badges30 silver badges43 bronze badges · Accepted Answer · 2018-05-24 16:05:51Z

It works because noImplicitAny does not affect variable declarations. If a variable is declared, but it's type is not declared, it is assumed any.

This was defined like that, because the compiler, despite the variable being any implicitly, can in fact determine its type at every point.

In fact, if you do this:

var a;
a = 5;
a.dot(); // error, number does not have a 'dot' property.
a = "hi";
a.foo(); // error, string does not have a 'foo' property.

You get an error, indicating that string has no property foo, or number has no property dot.

But, if you write:

function(b) {
 return b + 2;
}

This function, however, indicates an error because there is nothing that hints the compiler about what type b holds.

When did this change? Presumably with better flow analysis? I can remember getting "implicit any" errors for variables and can even get them when using typescript 1.8. For typescript 2.8 and the same code, there is no error as described here.
Yes. It changed around 2.1 or so. There was a PR about this. If the type can be determined by flow analisys, then there is not really an implicit any, even i f the variable can take any value of any type. As long as the type can be determined for every line of code in whuch it appears, there won't be an error.

CollectivesTM on Stack Overflow

Typescript types checking

3 Answers 3

3 Comments

4 Comments

Comments

Your Answer

Sign up or log in

Post as a guest

Post as a guest

Hot Network Questions

CollectivesTM on Stack Overflow

3 Answers 3

3 Comments

4 Comments

Comments

Your Answer

Sign up or log in

Post as a guest

Post as a guest

Related