[swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

[John McCall]

> On Mar 30, 2016, at 3:11 AM, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
>> On 25 Mar 2016, at 23:00, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> In the low level world, there is no such thing as an invalid address; both 0x0 and ~0x0 are perfectly valid byte pointers. So using something else than 0x0 for Swift invalid pointer just shuffle the problem around.
>> 
>> Let me state it this way: You cannot write a fully-conforming C compiler for a platform which does not have some way to represent an invalid pointer.
> 
> This is not true.
> 
> In both C99 and C11, the result of dereferencing an invalid pointer (of which the null pointer is one example) is undefined behaviour. This means it is perfectly fine for the null pointer to be represented by a bit pattern that is also a valid address and for the compiler not to bother generating a check that the pointer is not null. 

This is not correct.  Two pointers are not permitted to compare equal when one operand is a null pointer and the other is a pointer to an object.

John.

> 
>> However C does it, Swift can do the same thing.
> 
> C does it by sweeping the problem under the carpet of undefined behaviour.
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution