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

Dave Abrahams dabrahams at apple.com
Thu Mar 31 13:19:44 CDT 2016


on Wed Mar 30 2016, Jeremy Pereira <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) 

The null pointer is valid, it's just not dereferenceable.  Invalid
pointers can't even be compared with one another.

> 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.
>
>> 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

-- 
Dave



More information about the swift-evolution mailing list