<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 28, 2016, at 11:05 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello Swift community,<br class=""><br class="">The review of “SE-0107: UnsafeRawPointer API” begins now and runs through July 4, 2016. The proposal is available here:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md</a><br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class="">I've revised the proposal again based on extremely helpful feedback from DaveA and Jordan.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">You can see what changed in this pull request:</div><div class=""><a href="https://github.com/apple/swift-evolution/pull/408" class="">https://github.com/apple/swift-evolution/pull/408</a></div><div class=""><br class=""></div><div class="">Brief summary:</div><div class=""><br class=""></div><div class="">- Memory is dynamically bound to a single type.</div><div class=""><br class=""></div><div class="">- All typed access to memory, whether via a typed pointer or regular</div><div class=""> language construct, must be consistent with the memory's bound type</div><div class=""> (the access type must be related to the bound type). Typed access</div><div class=""> includes initialization, assignment, or deinitialization via a typed</div><div class=""> pointer.</div><div class=""><br class=""></div><div class="">- Memory remains bound after being deinitialized.</div><div class=""><br class=""></div><div class="">- Memory is implicitly bound or rebound to a type by initializing it</div><div class=""> via a raw pointer.</div><div class=""><br class=""></div><div class="">- A separate API now exists for explicity binding or rebinding memory</div><div class=""> to a type. This allows binding to be decoupled from initialization</div><div class=""> for convenience and efficiency. It also supports safe</div><div class=""> interoperability between APIs that used different, but layout</div><div class=""> compatible types.</div><div class=""><br class=""></div><div class="">- Using an API that accesses memory as a different type can now be</div><div class=""> accomplished by rebinding the memory. This effectively changes the</div><div class=""> type of any initialized values in memory. The compiler is still</div><div class=""> permitted to assume strict aliasing for accesses on either side of</div><div class=""> the operation that rebinds memory.</div><div class=""><br class=""></div><div class="">Andy</div></body></html>