Nullablity

[Brendan Eich]

On Jun 24, 2006, at 9:33 AM, P T Withington wrote:

> On 2006-06-23, at 13:14 EDT, Jeff Dyer wrote:
>
>> Clearly a proposal that allows AS3 code that is free
>> of null pointer errors to compile and run unchanged would be much
>> preferred to proposals that don't.
>
> Since I'm jumping in to the middle of this process, let me  
> summarize my understanding.  Tell me if I'm wrong:
>
> The proposal on the table is to make all types _not_ nullable by  
> default.  If a program has no null pointer errors, that should not  
> affect the program.  There is an implementation detail for compiler  
> writers that it is _not_ an error to have an uninitialized variable  
> so long as it is always initialized to a type-correct value before  
> it is read (requires flow analysis in the compiler).  It would be  
> easier for the compiler implementor to not permit that case in the  
> language, but I don't think that is being proposed -- such a change  
> _would_ break correct programs.

For better or worse, that is what is proposed the last I heard (I'm  
still on vacation, so I may be out of date).

Requiring definite assignment flow analysis is out, because of the  
desire for small/simple implementations that *do* include the  
optional but normatively-specified type checker.

Portable code should be able *not* to initialize a non-nullable  
variable as you say, so long as well-typed sets of that variable  
dominate all uses of the variable.

But AS3 and JScript.NET make Object, e.g., nullable, and people do  
write variable declarations (especially in classes) that are not  
initialized, not even obviously initialized in constructors before  
uses of those members.

What's more, some AS3 code is not incorrect (subject to NPEs) just  
because it mixes null into the value set for Object or other class- 
type-annotated variables.  A use-case I've heard of from the Flex SDK  
(ActionScript 3) is a non-rest (not trailing) parameter where passing  
null means "ignore this formal parameter".  With the proposed change  
to make types non-nullable by default, any call to such a function  
that passes null would fail to type-check.

Therefore, the only coherent paths forward are:

1.  Keep compatibility, making non-nullability optional and explicit.

2.  Break compatibility in ES4 with AS3 and JScript.NET, by making  
nullability optional and explicit.

3.  Break compatibility by making nullability optional and explicit,  
but require enough flow analysis to avoid calling existing patterns:

(a) Uninitialized declarations annotated with default-non-nullable  
types.
(b) A null actual parameter passed to a function taking a non- 
nullable formal parameter, where the AS3- or JScript.NET-compatible  
compiler has done extensive flow analysis and marked the parameter as  
implicitly nullable because it can prove that all dereferences of the  
formal are guarded by not-null tests.
(c) Variations on (b) involving other kinds of data flow than actual  
to formal parameter flow.

I singled out (b) because it seems solvable by backward-compatible  
compilers when generating code for the called function.  (c) may  
require global analysis including alias analysis (e.g., via package  
imports) that is quite expensive compared to the analysis needed for  
(b).

Jeff, is 3 too big a burden?  You may already have such flow analysis  
under way.

/be