Better type support

Topics: General, Language Specification
Oct 1, 2012 at 5:27 PM
Edited Oct 1, 2012 at 5:30 PM

(Cross-posting my HN comment at

This looks nice.

It'd be 100% more useful if it was more aware of nullable types -- as it is, it appears that null * 7 compiles without any error messages. If you guys add a "nullable number" type distinct from "number", I'll be a lot more likely to use it.

It also appears that some other things compile that perhaps shouldn't, such as 7[2] and 7["a"] even though (7).a is equivalent and (correctly) fails to compile.

Nice work. :)

Oct 1, 2012 at 9:00 PM

Thanks! Great suggestions!

Non-nullable types: There's a delicate balance we have to strike where the type system needs to be useful but not too complex. One guiding light for us here has been that toolability is more important than type safety. As non-nullness does little for e.g. auto-completion and comes with quite a lot of user-facing complexity, we've decided - for now! - not to track it. We note your feedback though; if this becomes a common request we'll take another look at it.

As for the typing of e.g. "null * 7" we can look at that separately from the above question. We do have a null type and could choose to reject this expression. A tradeoff with operators in general is that JavaScript is awash with operator-based idioms that are concise and useful but inherently "badly" typed. We don't want to police these too strongly so there needs to be some wiggle room. That said, we'll look at this case and see if there's some tightening up we can do without breaking idiomatic scenarios.

Finally, indexers: I am convinced we could have stronger typing here. In particular, since "dotting" in JavaScript is little more than syntactic sugar over indexing with constant strings, the type system could probably do a better job recognizing that and typingthose two syntaxes in a more similar fashion.

Thanks again for the great feedback!

Oct 1, 2012 at 11:39 PM

Agree with this.  Given that TS is adding a level of verifiability to the code at compile time it would be great to replace those asserts with something that the compiler can understand. 

In the same way I think adding an immutable decorator would also be useful.  Like C++ const, this could help verify the code - even if no javaScript was emitted.

Jun 10, 2013 at 8:43 AM
I would also like to see nullable types in typescript.

Nullable types have helped me statically find many bugs in my code with googles closure compiler. They forced me to always be very mindful about which values may be null, thus avoiding the equivalent of null pointer dereferencing:
var x: number or null;
var y = x.toPrecision(2); // Error: x may be null, accessing member 'toPrecision' of null
if (x != null) {
    var y = x.toPrecision(2); // OK: x can't be null
Note that for this to work, one needs flow-based type inference (the compiler has to realize that x can't be null after we check its value for null).

As for the syntax, in closure, all types are nullable by default, but one can explicitely specify this as in the below example. I think a similar syntax would fit the spirit of typescript where the core language is very relaxed and you can explicitely add strictness to your code.
  • "!number": a number (must not be null)
  • "?number": a number or null
  • "number": a number or null (default if not explicitely stated)
Jun 10, 2013 at 5:02 PM

I suspect this will make the type system feel more complex (as Mads mentions in the previous reply), though it's also something that someone could experiment with in a fork of the compiler to see how it plays out in practice.
Apr 2 at 2:17 PM
From my experience working with google closure, and F# option types, I find the nullability types very useful in finding bugs. When it comes to real world bugs, I'd probably trade nullability for all other type features! Right now this missing feature is one of the main things that is preventing me from wanting to switch from google closure compiler to wanting to work with typescript.