6 ms·

Non-nullable types for TypeScript

185 points by muraiki 11y ago

deleted 11y ago
[deleted]
raquo 11y ago
Looks like a good punch right into one of Facebook flow's advantages. Very glad to see both static typing alternatives for JS evolving.
cogware 11y ago
I'm really impressed with how quickly the Typescript team is adding new features - it feels like every time I check in on them they have something new in the works that I really care about. Great work!
vog 11y ago
Too bad that "strictNullChecks" is not the default behaviour. Because this is the only really sane default, and is one the the things I loved so much in strongly types languages such as OCaml, F# or Haskell. It reduces so make case distinctions (and forgotten if/switch checks) to the only places where these are really used. Also, "strictNullChecks" is kind of optional security, which is almost always a bad idea in the long run. Maybe they did this for backwards compatibility? Are there any plans to make "strictNullChecks" the default in the future?
- geon 11y ago
  Since this is a brand new feature that isn't even accepted into the language yet, it obviously can't be made default. If they decide to make it the default behavior, there would need to be a period where the old bahavior is depreciated and triggers warnings, but not errors. I hope the --noImplicitAny option will become default.
  - mc808 11y ago
    One of the most touted features is "your JavaScript is already valid TypeScript" (or pretty close), so I think they will keep the defaults so that JS developers can just change the .js to .ts and be up and running with as little friction as possible.
    - geon 11y ago
      Well, with the last release, typescriot supposedly can compile plain js. https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#including-js-files-with---allowjs https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in... That should make it simple to treat ts more strict than js.
      - masklinn 11y ago
        > Well, with the last release, typescriot supposedly can compile plain js. How does the ability to compile plain JS alter its goal of being a JS superset?
        jdmichal 11y ago
        Because it can compile plain JS using the rules present under plain JS, such as nullable and undefined-able types by default, regardless of the rules it's using to compile TS.
  - spion 11y ago
    It will never be the default, but its not a big deal as you can set it up in the project configuration options. Not sure why the default matters at all. The idea behind TS is to be able to gradually turn up the strictness dial as you migrate from JS
    - knocte 11y ago
      Yes but the ideal would be to know that if its extensions ends with .ts then it's strict, if it's .js then it still is crap.
- millstone 11y ago
  Languages like Haskell can get away with it because everything is statically compiled. But what would this look like for an environment like JS, that dynamically links against the user's browser? The user's browser may be older or newer, and expose different properties. Should every browser API be potentially nullable?
  - masklinn 11y ago
    That's no different than any other TS code having to interact with regular JS.
  - egeozcan 11y ago
    Potentially null features should be nullable and when not, it'll be a potential run-time error.
- spriggan3 11y ago
  It would break Typescript backward compatibility. Making it optional was the right thing to do.
- WorldMaker 11y ago
  Typescript leans in the direction for increasing strictness one flag at a time in a project, which is particularly fair if you're migrating a legacy project but not always the most sane option for new projects. In this case, too, there's a maintenance burden in that probably a bunch of type definitions files may need updating before this new strictness is usable in some projects. So there's a direct backward compatibility issue with existing Typescript code that will need to be addressed for this new strictness. One of the proposals I've seen in the GitHub issues is that Typescript should at least offer a "Maximum Strictness" option that turns on all of the optional strictness checks together, which would be great for fresh projects, with the assumption that new versions of Typescript present some maintenance requirements for those projects. I would love to see that added to Typescript.
ridiculous_fish 11y ago
Really glad to see this. I encountered the use-before-declaration "feature" of TS, and I just assumed it was a bug, which I filed. I was flabbergasted when I was told it was by design, to match JavaScript. The issue: https://github.com/Microsoft/TypeScript/issues/5822 https://github.com/Microsoft/TypeScript/issues/5822
- knocte 11y ago
  Wow what a bunch of pedants! I completely agree with the issue you raised, I had a better consideration of the TS team.
  - masklinn 11y ago
    I can only disagree and that thread gave me an excellent impression of the TS team[0]. They cleanly noted that this was expected behaviour, the reasoning behind it (which calls back to one of the underlying roles of typescript) and how to mitigate it. Can't say the same of your vote-spamming of every comment though. [0] as someone mostly uninterested in TS
- tom-lord 11y ago
  Funny how the conclusion is basically "Don't use `var`, use `let` instead" - even though almost all documentation/examples exclusively use the `var` keyword!
  - egeozcan 11y ago
    From Ryan Cavanaugh's comment[1]: > (...) there's already the let keyword available for those who want saner scoping rules. We should definitely update the docs to use let everywhere, though. [1]: https://github.com/Microsoft/TypeScript/issues/5822#issuecomment-161079139 https://github.com/Microsoft/TypeScript/issues/5822#issuecom...
    - tom-lord 11y ago
      Yes, however that was 3 and a half months ago -- and as far as I can tell, there's been no movement towards doing so.
flatline 11y ago
The Google Closure type system is much saner on this front already. A variable of a declared type cannot be undefined. Nullable and non-nullable types are distinct: primitives are non-nullable by default, with an option to make them nullable (?string, ?number, etc.), and types deriving from Object are nullable by default, with an option to make them non-nullable (!Object, !MyType, etc.) Of course JavaScript itself does not have a notion of nullable types, so touching any native API interfaces naturally leaves you with a bunch of nullable types where you may well know the value will never be null, so you are left trying to decide where to do nothing, where to add an assertion, and where to add a conditional branch. This ambiguity comes through the Closure API in many places that it would be nice to have a non-nullable type guarantee, but I suppose the library has evolved over time and further must be adaptable to a range of coding styles.
- pka 11y ago
  > and types deriving from Object are nullable by default So what's the point then?
  - munificent 11y ago
    You can flip the default. Back when I was using Closure Compiler, it was the expected convention on my team to mark most of your type annotations non-nullable.
- dmgd 11y ago
  you mean value types rather than primitives right? (Strings are objects) It would be saner if everything was non null by default. There'd be no need for a ! then and no ambiguity for beginners around whether something is nullable or not. No downside for non-beginners either unless they're in the habit of using more nullable parameters/vars than non-nullable, which doesn't seem like a particularly good idea...
  - flatline 11y ago
    Yes, value types, thank you. Agreed on the defaults, although you then have the problem of reconciling with the native JS type system. I'm unclear on what this PR does to address that for TS - in strict null check mode, can an e.g. Node be null by default? If so, does the native "Node" object then become "Node|null"? At some level this has to be addressed.
deleted 11y ago
[deleted]
kbsletten 11y ago
> A type guard for a dotted name has no effect if any part of the dotted name is the target of an assignment within the guarded code. For example, a type guard for x.y.z will have no effect if the guarded code contains any assignments to x, x.y, or x.y.z. This is interesting to me because it is: 1) Unnecessarily conservative. let x = { y: { z: intOrNull() } }; if (x && x.y && x.y.z) { const z = x.y.z; x.y = null; // z is of type "number?" when it could be "number" } 2) Not sound w.r.t. aliasing. let x = { y: { z: intOrNull() } }; let x_ = x; if (x && x.y && x.y.z) { x_.y.z = null; const z = x.y.z; // z is of type "number" with a value of "null" }

185 points by muraiki 11y ago

deleted 11y ago

[deleted]

raquo 11y ago

Looks like a good punch right into one of Facebook flow's advantages. Very glad to see both static typing alternatives for JS evolving.

cogware 11y ago

I'm really impressed with how quickly the Typescript team is adding new features - it feels like every time I check in on them they have something new in the works that I really care about. Great work!

vog 11y ago

Too bad that "strictNullChecks" is not the default behaviour. Because this is the only really sane default, and is one the the things I loved so much in strongly types languages such as OCaml, F# or Haskell. It reduces so make case distinctions (and forgotten if/switch checks) to the only places where these are really used. Also, "strictNullChecks" is kind of optional security, which is almost always a bad idea in the long run. Maybe they did this for backwards compatibility? Are there any plans to make "strictNullChecks" the default in the future?

geon 11y ago
Since this is a brand new feature that isn't even accepted into the language yet, it obviously can't be made default. If they decide to make it the default behavior, there would need to be a period where the old bahavior is depreciated and triggers warnings, but not errors. I hope the --noImplicitAny option will become default.
- mc808 11y ago
  One of the most touted features is "your JavaScript is already valid TypeScript" (or pretty close), so I think they will keep the defaults so that JS developers can just change the .js to .ts and be up and running with as little friction as possible.
  - geon 11y ago
    Well, with the last release, typescriot supposedly can compile plain js. https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#including-js-files-with---allowjs https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in... That should make it simple to treat ts more strict than js.
    - masklinn 11y ago
      > Well, with the last release, typescriot supposedly can compile plain js. How does the ability to compile plain JS alter its goal of being a JS superset?
      - jdmichal 11y ago
        Because it can compile plain JS using the rules present under plain JS, such as nullable and undefined-able types by default, regardless of the rules it's using to compile TS.
- spion 11y ago
  It will never be the default, but its not a big deal as you can set it up in the project configuration options. Not sure why the default matters at all. The idea behind TS is to be able to gradually turn up the strictness dial as you migrate from JS
  - knocte 11y ago
    Yes but the ideal would be to know that if its extensions ends with .ts then it's strict, if it's .js then it still is crap.
millstone 11y ago
Languages like Haskell can get away with it because everything is statically compiled. But what would this look like for an environment like JS, that dynamically links against the user's browser? The user's browser may be older or newer, and expose different properties. Should every browser API be potentially nullable?
- masklinn 11y ago
  That's no different than any other TS code having to interact with regular JS.
- egeozcan 11y ago
  Potentially null features should be nullable and when not, it'll be a potential run-time error.
spriggan3 11y ago
It would break Typescript backward compatibility. Making it optional was the right thing to do.
WorldMaker 11y ago
Typescript leans in the direction for increasing strictness one flag at a time in a project, which is particularly fair if you're migrating a legacy project but not always the most sane option for new projects. In this case, too, there's a maintenance burden in that probably a bunch of type definitions files may need updating before this new strictness is usable in some projects. So there's a direct backward compatibility issue with existing Typescript code that will need to be addressed for this new strictness. One of the proposals I've seen in the GitHub issues is that Typescript should at least offer a "Maximum Strictness" option that turns on all of the optional strictness checks together, which would be great for fresh projects, with the assumption that new versions of Typescript present some maintenance requirements for those projects. I would love to see that added to Typescript.

ridiculous_fish 11y ago

Really glad to see this. I encountered the use-before-declaration "feature" of TS, and I just assumed it was a bug, which I filed. I was flabbergasted when I was told it was by design, to match JavaScript. The issue: https://github.com/Microsoft/TypeScript/issues/5822 https://github.com/Microsoft/TypeScript/issues/5822

knocte 11y ago
Wow what a bunch of pedants! I completely agree with the issue you raised, I had a better consideration of the TS team.
- masklinn 11y ago
  I can only disagree and that thread gave me an excellent impression of the TS team[0]. They cleanly noted that this was expected behaviour, the reasoning behind it (which calls back to one of the underlying roles of typescript) and how to mitigate it. Can't say the same of your vote-spamming of every comment though. [0] as someone mostly uninterested in TS
tom-lord 11y ago
Funny how the conclusion is basically "Don't use `var`, use `let` instead" - even though almost all documentation/examples exclusively use the `var` keyword!
- egeozcan 11y ago
  From Ryan Cavanaugh's comment[1]: > (...) there's already the let keyword available for those who want saner scoping rules. We should definitely update the docs to use let everywhere, though. [1]: https://github.com/Microsoft/TypeScript/issues/5822#issuecomment-161079139 https://github.com/Microsoft/TypeScript/issues/5822#issuecom...
  - tom-lord 11y ago
    Yes, however that was 3 and a half months ago -- and as far as I can tell, there's been no movement towards doing so.

flatline 11y ago

The Google Closure type system is much saner on this front already. A variable of a declared type cannot be undefined. Nullable and non-nullable types are distinct: primitives are non-nullable by default, with an option to make them nullable (?string, ?number, etc.), and types deriving from Object are nullable by default, with an option to make them non-nullable (!Object, !MyType, etc.) Of course JavaScript itself does not have a notion of nullable types, so touching any native API interfaces naturally leaves you with a bunch of nullable types where you may well know the value will never be null, so you are left trying to decide where to do nothing, where to add an assertion, and where to add a conditional branch. This ambiguity comes through the Closure API in many places that it would be nice to have a non-nullable type guarantee, but I suppose the library has evolved over time and further must be adaptable to a range of coding styles.

pka 11y ago
> and types deriving from Object are nullable by default So what's the point then?
- munificent 11y ago
  You can flip the default. Back when I was using Closure Compiler, it was the expected convention on my team to mark most of your type annotations non-nullable.
dmgd 11y ago
you mean value types rather than primitives right? (Strings are objects) It would be saner if everything was non null by default. There'd be no need for a ! then and no ambiguity for beginners around whether something is nullable or not. No downside for non-beginners either unless they're in the habit of using more nullable parameters/vars than non-nullable, which doesn't seem like a particularly good idea...
- flatline 11y ago
  Yes, value types, thank you. Agreed on the defaults, although you then have the problem of reconciling with the native JS type system. I'm unclear on what this PR does to address that for TS - in strict null check mode, can an e.g. Node be null by default? If so, does the native "Node" object then become "Node|null"? At some level this has to be addressed.

deleted 11y ago

[deleted]

kbsletten 11y ago

> A type guard for a dotted name has no effect if any part of the dotted name is the target of an assignment within the guarded code. For example, a type guard for x.y.z will have no effect if the guarded code contains any assignments to x, x.y, or x.y.z. This is interesting to me because it is: 1) Unnecessarily conservative. let x = { y: { z: intOrNull() } }; if (x && x.y && x.y.z) { const z = x.y.z; x.y = null; // z is of type "number?" when it could be "number" } 2) Not sound w.r.t. aliasing. let x = { y: { z: intOrNull() } }; let x_ = x; if (x && x.y && x.y.z) { x_.y.z = null; const z = x.y.z; // z is of type "number" with a value of "null" }