Nullablity

[Nicolas Cannasse]

> But I've also heard a credible argument during the design process: that 
> the majority of JS code on the web is tiny little fragments, one liners, 
> often fragments that only run zero or one times, and sometimes running 
> on a cell phone. Keeping the "defaults" easy to compile is a priority 
> for at least some of the language implementers. This means dataflow 
> algorithms are unappealing: local expression-type inference is about all 
> we want to pay for. We do not want to reimplement Java's definite 
> assignment rules or similar.

Definite assignement would surely be the best way to ensure that a "T" 
(or "T!") variable is correctly assigned. The two other ways to ensure 
type-safety of these variables are :

a) forbid "var" declaration without an initialization expression. This 
is a form of very strict definite assignement since no delay is even 
permited

b) have a runtime error. That's not what I would call "type-safety" 
since it's just a kind of Null Pointer Exception just a bit before the 
pointer is actually accessed.

 From what I've seen, ES4 will not target the user that just want to 
open a popup on his website or do some basic form validation. But when 
you start using the type system, you should be able to rely on it.

Since you're not going the type-inference way, accessing strictly-typed 
API with untyped code should not cause any problem, unless the user pass 
an explicit "null" value where an not-nullable instance is required.

Or maybe I forgot something ?

Nicolas