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

[Richard Ross]

> * What is your evaluation of the proposal?

Currently, I'm -0.8 on this, for a few reasons.

Firstly, UnsafePointers are explicitly 'Unsafe' already. Making them more 'safe' could encourage more widespread usage of them, when in reality they're not necessary for 90% of cases.

Secondly, we will run into the IOU situation for C (and hopefully eventually C++) APIs, that now need to be audited and updated to reflect nullability status, which I'd wager that most existing headers *won't* be audited, especially on linux.

Thirdly, as mentioned in the prior discussion it's certainly possible on some platforms to remap the memory page at address 0x0 and make it usable to userland code. Even if we don't currently support any such platforms, we shouldn't lock ourselves into a situation where we need to be able to do this.

Finally, having nullable UnsafePointers currently is the only way from swift code to convert an UnsafePointer to an Int of its raw address, short of using another level of indirection:

let rawAddress: Int = UnsafePointer<UInt8>(nil).distanceTo(myPointer)

Unless the other proposal that's in the works to get the raw address of an UnsafePointer goes through (which I'm a supporter of), this would remove a very important functionality from the swift language, especially when dealing with lower level APIs that can take pointers as integers.

> * Is the problem being addressed significant enough to warrant a change to Swift?


I think the goal of being able to write safer code is a noble one, and one we should strive for overall in the language. However, I don't believe that this is enough of an approach, nor is it inherently 'safer' (as nothing stops you from creating another invalid pointer that crashes rather than just NULL). Unless we plan on having some way to confirm that a pointer is, in fact, valid, I think we should leave UnsafePointer in its 'unsafe' state.

> * Does this proposal fit well with the feel and direction of Swift?

I actually think it does. This will provide a swift-ier interface with raw pointers (and causing less confusion amongst beginners (who probably shouldn't be using UnsafePointer, but still) and improving API contracts). Again, however, UnsafePointer, while powerful, is rarely the proper tool for the job, and I think should be left in its current state - powerful, but difficult to use, to prevent a foot-gun scenario like we see in C++ and references (ask any C++ beginner about the lifetime of a reference...)

> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I'm actually unsure of any other languages that have explicit nullability on a raw pointer type. (Maybe rust has it? I'm not very familiar with rust).

> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I've been following the proposal since day 1, and have put a lot of thought into it (one of my current projects uses UnsafePointer quite a bit). I'd like to think that I did a rather in-depth review of the subject.

If you've made it this far, thanks for reading my thesis on UnsafePointer :)
--
Richard

> On Mar 24, 2016, at 11:00 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift community,
> 
> The review of "Make unsafe pointer nullability explicit using Optional" begins now and runs through March 29th. The proposal is available here:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
> 
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
> 	https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=Ezje1IF3xGXfUMfsj4fBc7oM7BcJys1dhQ6psfXzLMU&m=_MgWpo4MYLScsGzB9CqrI-eCyzjjkWNyv8hjBeDANw0&s=HZtE3Eh63CLwxWA4MExIZyp1Dn7CsH2Te9eRrsFZNfE&e= 
> or, if you would like to keep your feedback private, directly to the review manager.
> 
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
> 
> 	* What is your evaluation of the proposal?
> 	* Is the problem being addressed significant enough to warrant a change to Swift?
> 	* Does this proposal fit well with the feel and direction of Swift?
> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
> 	https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=Ezje1IF3xGXfUMfsj4fBc7oM7BcJys1dhQ6psfXzLMU&m=_MgWpo4MYLScsGzB9CqrI-eCyzjjkWNyv8hjBeDANw0&s=HZtE3Eh63CLwxWA4MExIZyp1Dn7CsH2Te9eRrsFZNfE&e=