GeezerVison

fancy 😎

🍺 is it enabled by default? impact on performance?

Anders Hejlsberg (@ahejlsberg) I've addressed your comments, can you please take another look to see if everything looks good from your perspective?

Vladimir Matveev (@vladima) noImplicitReturns doesn't seem to catch the following function:

function foo(x: number) {
    if (x < 0) return 42;

}

Daniel Rosenwasser (@DanielRosenwasser) noImplicitReturns is enabled if return type is specified

function foo(x: number): number {
    if (x < 0) return 42;

}

v2m@v2m-ThinkPad-W520:~/sources/TypeScript$ node built/local/tsc.js test.ts --noImplicitReturns
test.ts(1,26): error TS7030: Not all code paths return a value.

Vladimir Matveev (@vladima) yes, I wasn't sure if that was intentional or not. I think that's a little too subtle. I would assume you are more likely to forget a type annotation as you are an explicit return, and the switch is "no implicit returns".

currently implemented behavior is aligned with our existing approach to report errors on missing return or throw only if user explicitly opted in (by using return type annotation). However I do see how it might be subtle especially now it is kind of double opt-in (first via command line switch and second - by explicitly specifying return type) - this behavior can always be adjusted

This is fantastic! We love preventing bugs.

I'm curious if the team has discussed how to classify which static analysis will be included in the compiler, vs. what would be in something like tslint.
Our experience at Google is that optional tooling is underused and much less effective. (we're writing a paper on it which I hope to share soon - cc Eddie Aftandilian (@eaftan)).
As a trivial example, we found a handful of occurrences of a bug like:

if (condition);
  throw new IllegalState();

in Google's code, and this is very easily prevented by disallowing "empty" if statements with no then/else blocks.

Do you imagine adding many more compilerOptions like the new --noImplicitReturns added in this PR?

Anders Hejlsberg (@ahejlsberg) can you please check if your time measurements got better with last commit?

Vladimir Matveev (@vladima) Just ran my RWC Monaco tests. With the latest changes we're now consistently a little bit faster than 1.6 even with reachability checks. Good stuff.

👍

What about the tsconfig.json schema? Shouldn't it be updated?