I appreciate Typescript remaining opt-in for all of these things (as that seems a clear goal of the project, --noImplicitAny has been like that since very early on), but it would be nice to have some sort of intentional signifier flag --maximumStrictness or whatever you want to call it that does a rolling opt-in to all the strictest checks as new ones are invented.

It's a tough call, and I can see arguments for both sides. On the other side, one of the big selling points of TypeScript is that you can take your existing huge JavaScript codebase, and with little effort turn it into TypeScript with all the types being "any", then gradually add strong types as time permits. This wouldn't work if --strictNullChecks was the default and would add one more step to the migration process.

`null` and `undefined` are subtypes of `any`, so you can still gradually convert to typescript.

(according to https://github.com/Microsoft/TypeScript/pull/7140)

I don't use TypeScript, but with Flow (which has always disallowed nulls in built-in and user-defined types by default), "null" is a subtype of "any", so that would still work. Is this not the case in TypeScript with --strictNullChecks?

> and with little effort turn it into TypeScript

Good point, but then how about an opt-out warning (instead of error)?

Wouldn't that break third party libraries? You'd also need a compiler flag to enable it only for your own code.

I feel that typescript being only 2.0, should be in a position to break things once in a while.

If you pay too much attention to keeping legacy code 'alive' you end up complicating matters with either compiler-flags all over the place or redundant API's i.e win32 api (old+new+newer versions of the same function).

The fact that the flag is global could actually slow down adoption of the new type system.

Let's say I want to use the new type system, but some library I depend on hasn't been updated. If I enable the new type system, I'll get both false positives and negatives when type checking.

If a library writer updated to the new type system, they'd break compatibility with callers that haven't updated. The safest option would be to maintain two almost-identical copies of the library -- one for the old type system and one for the new one.

A better option would be to allow specifying the type system mode at the top of each file (like "use strict"). This allows me to use the new type system even if not all my libraries have updated yet. This also allows libraries writers to use the new type system features without breaking existing users.