[swift-evolution] [Review] SE-0107: UnsafeRawPointer API (binding memory to type)

[Andrew Trick]

> On Jun 28, 2016, at 11:05 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> Hello Swift community,
> 
> 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've revised the proposal again based on extremely helpful feedback from DaveA and Jordan.

This revision expands on the concept of formally binding the memory type that I was recently working on with Dmitri. Now we can clearly define pre and post conditions on memory operations and pointer casts that can be used to prove the type safety. The model is now simpler, more complete, and easy to reason about locally. This will help developers reason about correctness and make it easy to implement a sanitizer that verifies the type safety of UnsafePointer operations.

Adding safety to pointer "casts" made it possible for me to actually simplify the allocation and initialization APIs. I think both camps, convenience and safety, will be happy.

You can see what changed in this pull request:
https://github.com/apple/swift-evolution/pull/408 <https://github.com/apple/swift-evolution/pull/408>

Brief summary:

- Memory is dynamically bound to a single type.

- All typed access to memory, whether via a typed pointer or regular
  language construct, must be consistent with the memory's bound type
  (the access type must be related to the bound type). Typed access
  includes initialization, assignment, or deinitialization via a typed
  pointer.

- Memory remains bound after being deinitialized.

- Memory is implicitly bound or rebound to a type by initializing it
  via a raw pointer.

- A separate API now exists for explicity binding or rebinding memory
  to a type. This allows binding to be decoupled from initialization
  for convenience and efficiency. It also supports safe
  interoperability between APIs that used different, but layout
  compatible types.

- Using an API that accesses memory as a different type can now be
  accomplished by rebinding the memory. This effectively changes the
  type of any initialized values in memory. The compiler is still
  permitted to assume strict aliasing for accesses on either side of
  the operation that rebinds memory.

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160704/68afea3c/attachment.html>