[swift-evolution] Making pointer nullability explicit (using Optional)

[Jordan Rose]

> On Mar 18, 2016, at 13:11 , Félix Cloutier <felixcca at yahoo.ca> wrote:
> 
> GCC may have some hints:
> 
>> -fdelete-null-pointer-checks
>> Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. This option enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that a memory access to address zero always results in a trap, so that if a pointer is checked after it has already been dereferenced, it cannot be null.
>> Note however that in some environments this assumption is not true. Use -fno-delete-null-pointer-checks to disable this optimization for programs that depend on that behavior.
>> 
>> This option is enabled by default on most targets. On Nios II ELF, it defaults to off. On AVR and CR16, this option is completely disabled.
>> 
>> Passes that use the dataflow information are enabled independently at different optimization levels. 
> 
> I recall that my first time being bit by null being valid was on AVR32 (though with GCC 3.something), and this seems to confirm it.

In an offline conversation Doug pointed out that Clang and LLVM also assume that NULL is 0, so there'd be a lot more work than just improving Swift to make Swift work on such a platform. I think when the time comes the implementer for such a platform can designate a non-zero bit pattern to use as an invalid pointer instead.

Jordan