<div dir="ltr"><div>This is the first version of this proposal which I've had time to read. I like it a lot overall. If I have some more time, I may try pulling the branch and writing some code with it to see how it feels. (If we could get a toolchain built from the branch, that might help others review it.)</div><div><br></div><div>Here are a handful of minor comments:</div><div><br></div><div>- Naming: "bindMemory(to:capacity:)", being "verb-ish", seems incongruous with "assumingMemoryBound(to:)" and "withMemoryRebound(to:capacity:_:)". How about "bindingMemory(to:capacity:)" ?</div><div><div><br></div><div>- Would it be possible for "+(UnsafeRawPointer, Int) -> UnsafeRawPointer" to accept any Integer or FixedWidthInteger, rather than only Int?</div><div><br></div><div>- Why allow/encourage multiple calls to bindMemory on the same RawPointer? These APIs do a good job of making aliasing explicit by introducing data dependencies between pointers (you can only use a typed pointer after obtaining it from a raw pointer, and you can recover the raw pointer for later use by deinitializing the typed pointer). So, I would think the guidelines should prefer bindMemory to be used only once on a particular RawPointer value.</div><div><br></div><div>And minor notes about the proposal itself:</div><div><br></div><div>- strideof(Int.self) is used in most examples, but sizeof(Int.self) appears in one of them (the "normalLifetime()" example).</div><div><br></div><div>- I think there must be a mistake in this example, because pA is already bound and bindMemory was only defined for untyped RawPointers:</div><div><br></div><div><div> func testInitAB() {</div><div> // Get a raw pointer to (A, B).</div><div> let p = initAB()</div><div><br></div><div> let pA = p.bindMemory(to: A.self, capacity: 1)</div><div> printA(pA)</div><div><br></div><div> printB((pA + 1).bindMemory(to: B.self, capacity: 1)) //<<< should this be (p+1) rather than (pA+1)?</div><div> }</div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
<br><div class="gmail_quote">On Mon, Jul 4, 2016 at 3:32 PM, Andrew Trick via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jun 28, 2016, at 11:05 PM, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:</div><br><div><div>Hello Swift community,<br><br>The review of “SE-0107: UnsafeRawPointer API” begins now and runs through July 4, 2016. The proposal is available here:<br><br><span style="white-space:pre-wrap"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md</a><br></div></div></blockquote></div><div><br></div><div>I've revised the proposal again based on extremely helpful feedback from DaveA and Jordan.</div><div><br></div><div>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><br></div><div>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><br></div><div>You can see what changed in this pull request:</div><div><a href="https://github.com/apple/swift-evolution/pull/408" target="_blank">https://github.com/apple/swift-evolution/pull/408</a></div><div><br></div><div>Brief summary:</div><div><br></div><div>- Memory is dynamically bound to a single type.</div><div><br></div><div>- All typed access to memory, whether via a typed pointer or regular</div><div> language construct, must be consistent with the memory's bound type</div><div> (the access type must be related to the bound type). Typed access</div><div> includes initialization, assignment, or deinitialization via a typed</div><div> pointer.</div><div><br></div><div>- Memory remains bound after being deinitialized.</div><div><br></div><div>- Memory is implicitly bound or rebound to a type by initializing it</div><div> via a raw pointer.</div><div><br></div><div>- A separate API now exists for explicity binding or rebinding memory</div><div> to a type. This allows binding to be decoupled from initialization</div><div> for convenience and efficiency. It also supports safe</div><div> interoperability between APIs that used different, but layout</div><div> compatible types.</div><div><br></div><div>- Using an API that accesses memory as a different type can now be</div><div> accomplished by rebinding the memory. This effectively changes the</div><div> type of any initialized values in memory. The compiler is still</div><div> permitted to assume strict aliasing for accesses on either side of</div><div> the operation that rebinds memory.</div><div><br></div><div>Andy</div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div></div>