> On Jun 28, 2016, at 11:05 PM, Chris Lattner <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
