[swift-evolution] [Review] SE-0107: UnsafeRawPointer API

[Andrew Trick]

> On Jul 5, 2016, at 10:09 AM, Magnus Ahltorp via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> The review of “SE-0107: UnsafeRawPointer API” begins now and runs through July 4, 2016. The proposal is available here:
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md
> 
> I have not had time for a full review, but I have a question about the proposal:
> 
> When glancing at the examples, they strike me as mostly being marshalling, which in my opinion would be better served by a safe marshalling API followed by unsafe handling of the resulting buffer, and vice versa for unmarshalling. I think it is very important (in the long run) that code that doesn't interact with C directly has safe ways of doing inherently safe operations, and not take the unsafe route just because that is the only API available.
> 
> My question is, how does this API fit into the bigger picture of marshalling, and what are the benefits of using this API instead of marshalling with safe buffers?
> 
> I would consider "we don't have time, we have to do this for now" a perfectly valid answer.
> 
> /Magnus


I think that's a good point.

The examples in the "Motivation" section are contrived to demonstrate safety holes as tersely as possible. The examples in "Expected use
cases" are prototypical use cases that I expect most uses to fall under.

I think APIs for marshalling should evolve toward higher abstraction and safety. For starters, they should probably use UnsafeBufferPointer more often than UnsafePointer. But those APIs need time to evolve. The important thing for this release is to settle on the source-breaking changes to UnsafePointer and establish clear, verifiable rules for safety at the lowest level of the API.

One of the conundrums of this proposal is that well designed APIs should not need to use UnsafeRawPointer, but it does need to exist as the sanctioned way to work around limitations of UnsafePointer. If UnsafePointer is the *only* way to directly access a memory buffer, then it's natural for users to assume that they can use it as a valid workaround for all the messy interoperability, marshalling, and low-level buffer access problem that they face in practice. The situation today is that the UnsafePointer API encourages that misuse, and we possibly miscompile the code without warning.

-Andy