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

[Chris Lattner]

Felix, I understand what you're saying, but I still don't see how it shapes this discussion.  There are many things you can't do at that level of system programming in pure swift at the moment, and there are better ways to solve those problems later than to make UnsafePointer bear the burden for an extremely narrow use case.

Swift had no notion of volatile pointers for example.

-Chris

> On Mar 17, 2016, at 10:09 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
> 
> Well, they can also choose to not conform, or someone could use something lower-level than C to put something useful at address 0. I don't have any recent example, but for instance, in real mode, x86 has its interrupt descriptor table starting at 0.
> 
> It's true that it's a net win if you do app development, and it's probably a net win in most other cases too, but I just think that it's a little scary to make it 100% impossible to access anything at address 0. It's a tiny thing but it would make Swift the wrong tool if you ever needed to do it for whatever whacky reason that shouldn't exist in theory but ends up there in practice.
> 
> (My objection entirely goes away if `ptr!.pointee` tries to dereference the null address, but I think that this requires more compiler magic.)
> 
> Félix
> 
>> Le 18 mars 2016 à 00:32:38, Chris Lattner <clattner at apple.com> a écrit :
>> 
>>> On Mar 17, 2016, at 8:21 PM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>> Fortunately, when a type has a single invalid value for which no operations are valid, Swift already has a solution: Optionals.
>>> 
>>> To me, this makes it sound like dereferencing an unsafe pointer is unsafe only if the pointer is nil. (Nil does have the merit that it's generally one of the only addresses known to be invalid, though.)
>>> 
>>> One thing that I would worry about, though, is the case where dereferencing address 0 is legal. My understanding is that Swift is aimed to be a systems language, and this case is relatively frequent on embedded devices.
>> 
>> This is definitely an important case to consider, but I don't think this is a problem for the proposal.
>> 
>> C compilers for these sorts of embedded systems have two choices: they can either reserve 1 byte for the null value (wasting a byte of physmem) or they can use a null value with a representation that is not equal to zero.
>> 
>> In either case, the null value (whatever it is) maps to the swift none case.  Everything works out properly.
>> 
>> -Chris
>> 
>> 
>>> Félix
>>> 
>>>> Le 17 mars 2016 à 21:59:49, Jordan Rose via swift-evolution <swift-evolution at swift.org> a écrit :
>>>> 
>>>> Hey, everyone. If you're like me, you're sick of the fact that 'UnsafePointer<Int>' doesn't tell you whether or not the pointer can be nil. Why do we need to suffer this indignity when reference types—including function pointers!—can distinguish "present" from "absent" with the standard type 'Optional'? Well, good news: here's a proposal to make pointer nullability explicit. 'UnsafePointer<Int>?' can be null (nil), while 'UnsafePointer<Int>' cannot. Read on for details!
>>>> 
>>>> https://github.com/jrose-apple/swift-evolution/blob/optional-pointers/proposals/nnnn-optional-pointers.md
>>>> 
>>>> Bonus good news: I've implemented this locally and updated nearly all the tests already. Assuming this is accepting, the actual changes will go through review as a PR on GitHub, although it's mostly going to be one big mega-patch because the core change has a huge ripple effect.
>>>> 
>>>> Jordan
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160319/eba3e564/attachment.html>