default constructors and implicit super() insertion

Brendan Eich brendan at
Wed Jun 27 13:44:10 PDT 2007

[Jumping in on one point only, I'll hope to help Lars get back to  
vacation so he can reply in full later :-P]

On Jun 27, 2007, at 12:00 PM, Peter Hall wrote:

>> For JS, this means
>> having a straightforward compiler that performs the minimum amount of
>> analysis, incroporating quick-and-dirty code generation, and so on.
>> (Strict mode may be beyond such an implementation.)
> I was under the impression that this discussion would not apply in
> non-strict mode. Would it be an error to not initialize a non-nullable
> variable in non-strict mode?

Yes, otherwise you have just renamed NPE to UE for no win, and then  
what's the point of non-nullable types.

The intuition should be familiar to anyone who has written fast low- 
level C or C++ code. Your instance has pointer members, they are  
guaranteed non-null by the constructor or an initialization routine,  
any failure during constructor/initialization propagates and disposes  
of the half-initialized newborn. Thus all methods post initialization  
need never check for null, and you never get a null pointer crash.

This is common, even required (certainly in kernel land -- I used to  
be a Unix kernel hacker).

Non-nullable types should capture this use case. They ought to  
eliminate stupid NPEs that I've seen (and still see) from Java and C#  
web apps. Even though those languages have more fancy analysis than  
we are proposing for ES4, their type systems still cannot rule out an  
NPE statically or otherwise.

So we really do want non-nullably-typed class vars to be initialized  
by the time the constructor finishes, and as Dave Herman reminded me,  
the settings design goes further: it avoids UEs while the constructor  
is active, by forcing non-nullably-typed vars to be set early, and  
without reference to |this| or to other non-nullable vars.


More information about the Es4-discuss mailing list