Hacker News Reader

Comment by vog | Hacker News Reader

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?

View on HN

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.

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.

Well, with the last release, typescriot supposedly can compile plain js.

https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in...

That should make it simple to treat ts more strict than js.

> 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?

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.

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

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.

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.

It would break Typescript backward compatibility. Making it optional was the right thing to do.

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?

That's no different than any other TS code having to interact with regular JS.

Potentially null features should be nullable and when not, it'll be a potential run-time error.

Reply on news.ycombinator.com