brendan at mozilla.org
Sat Jun 24 07:47:48 PDT 2006
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
(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
Jeff, is 3 too big a burden? You may already have such flow analysis
More information about the Es4-discuss