`7[2]` is valid Javascript, so it is also valid TypeScript (fetching the '2' member of the `7` object).

Detecting null expressions at compile time might help. There are "nullable" types, but afaik only in signatures:

  foo(x?) {
      alert(x);
  }

If `x` is not passed in, it will be `undefined`.

"wingspan" * 7 is also gramatically correct JavaScript, but evaluates to NaN and almost certainly isn't what you want in your JS program, which is why TypeScript prints a type error (well, warning) if you try to compile it.

Having optional variables is similar, but not the same as nullable types, especially when the compiler can't enforce non-nullable-ness. All JS devs are familiar with the annoying error "'null' is not an object" (and anyone who's programmed in a language like Haskell, OCaml, or F# knows the value of sophisticated compile-type type checking).

Yes I see what you mean, it'd be interesting to see what the exact rules around type checking are; especially when dealing with []. The string type for example, always give you a string when indexed, even when incorrect:

  var s = 'foo';
  var l = s['length'];
  // type of l is `string`

I also agree about non-nullable types, and I've found even with TypeScript, having to make sure your vars are defined and not-null is still a pain.

> var s = 'foo';

> var l = s['length'];

> // type of l is `string`

beg pardon?

    $ js
    js> var s = 'foo';
    js> s['length'];
    3
    js> typeof s['length'];
    number

    $ node
    > var s = 'foo';
    undefined
    > s['length'];
    3
    > typeof s['length'];
    'number'

Please read the whole post for context. I am talking about the type system in TypeScript thinking that `l` is a string (which you can find out, for instance, by hovering over the `var` keyword in Visual Studio), when in fact, as you pointed out, it is a number. I assume this is because TypeScript caters to the most common case of indexing a string to obtain a single character (another string, basically).