12 ms·

> In TypeScript 2.0, the new --strictNullChecks flag changes that. string just means string and number means number. This is great. However, it would be nice t

by knocte 10y ago

> In TypeScript 2.0, the new --strictNullChecks flag changes that. string just means string and number means number. This is great. However, it would be nice to know if this feature will become opt-out in the future instead of opt-in. In theory, if you're a TS user (as opposed to JS) it's because you want these nice features _by default_.

hockeybias 10y ago
Agreed!
oblio 10y ago
Wouldn't that break third party libraries? You'd also need a compiler flag to enable it only for your own code.
- kagia 10y ago
  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).
  - cakoose 10y ago
    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.
Analemma_ 10y ago
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.
- knocte 10y ago
  > and with little effort turn it into TypeScript Good point, but then how about an opt-out warning (instead of error)?
- kcorbitt 10y ago
  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?
- legulere 10y ago
  `null` and `undefined` are subtypes of `any`, so you can still gradually convert to typescript. (according to https://github.com/Microsoft/TypeScript/pull/7140 https://github.com/Microsoft/TypeScript/pull/7140)
WorldMaker 10y ago
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.

by knocte 10y ago

hockeybias 10y ago

Agreed!

oblio 10y ago

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

kagia 10y ago
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).
- cakoose 10y ago
  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.

Analemma_ 10y ago

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.

knocte 10y ago
> and with little effort turn it into TypeScript Good point, but then how about an opt-out warning (instead of error)?
kcorbitt 10y ago
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?
legulere 10y ago
`null` and `undefined` are subtypes of `any`, so you can still gradually convert to typescript. (according to https://github.com/Microsoft/TypeScript/pull/7140 https://github.com/Microsoft/TypeScript/pull/7140)

WorldMaker 10y ago

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.