<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Jun 24, 2016, at 12:58 PM, Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 24, 2016, at 8:19 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Andrew, thank you for working on this. The latest draft is much improved!<div class=""><br class=""></div><div class="">I have a few questions.</div><div class=""><br class=""></div><div class="">Why do you require explicitly passing the type in these signatures?</div><div class=""><br class=""></div><div class="">func initialize<T>(_: T.Type, with: T, count: Int = 1) -> UnsafeMutablePointer<T></div><div class="">func initialize<T>(toContiguous: T.Type, atIndex: Int, with: T) -> UnsafeMutablePointer<T></div><div class="">func storeRaw<T>(_: T.Type, with: T)<br class="">func storeRaw<T>(toContiguous: T.Type, atIndex: Int, with: T)</div><div class=""><br class=""></div><div class="">There is probably a good reason, but it seems redundant at first glance and isn’t obvious from my reading of the proposal. The alternatives would be something like this:</div><div class=""><br class=""></div><div class="">func initialize<T>(with: T, count: Int = 1) -> UnsafeMutablePointer<T></div></div></div></blockquote><div><br class=""></div><div>Good question. It is deliberately, and unfortunately redundant. We're trading convenience for safety. I added this note to the proposal:</div><div><br class=""></div><div>Note that the `T.Type` argument on `initialize` is redundant because</div><div>it may be inferred from the `with` argument. However, relying on type</div><div>inferrence at this point is dangerous. The user needs to ensure that</div><div>the raw pointer has the necessary size and alignment for the</div><div>initialized type. Explicitly spelling the type at initialization</div><div>prevents bugs in which the user has incorrectly guessed the inferred</div><div>type.</div></div></div></blockquote><div><br></div>I suspected it was something like this. Thanks for explaining and updating the proposal!<div><br><blockquote type="cite"><div><div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">The parameter order in this signature is the opposite of the order in UnsafeMutablePointer. Is that intentional? If so, what is the rationale? You might want to elaborate this in the proposal.</div><div class=""><br class=""></div><div class="">public func + (lhs: Int, rhs: UnsafeRawPointer) -> UnsafeRawPointer</div></div></div></blockquote><div><br class=""></div>Fixed.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Shouldn’t the precondition be that memory for all elements is *uninitialized* / *deinitialized* in this example?</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(51, 51, 51);" class=""><span class="pl-c" style="box-sizing: border-box; color: rgb(150, 152, 150);">// - precondition: memory for all elements is initialized.</span>
<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">freeCBuffer</span>() {
UnsafeRawPointer(ptrToA)<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">.</span>deallocate(capacity: eltCount, of: A<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">.</span><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">self</span>)
}</pre><div class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div>Typo. Thanks!</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">It looks like there is a type in this example:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(51, 51, 51);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">var</span> anyT <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> T(<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">...</span>)
takesTPtr(<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">&</span>anyT)
takesVoidPtr(<span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">&</span>any)</pre><div class=""><br class=""></div></div><div class="">Should the last line say `&anyT`?</div></div></div></div></blockquote><div><br class=""></div>Typo. Thanks!</div><div><br class=""></div><div>-Andy</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Other than these few questions all I can say is that this looks great! I believe it will add important clarity to code that works with unsafe pointers.</div><div class=""><br class=""></div><div class="">-Matthew</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 23, 2016, at 8:40 PM, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I sent two RFC's for this proposal over the past couple months (see Early swift-evolution threads). High-level feedback was fairly light. This version is a final draft, as I expect it to go through the review process next week. There is a lot more explanation and detail in this proposal now, and the memory model has been simplified and clarified.<br class=""><br class=""><a href="https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/XXXX-unsaferawpointer.md" class="">https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/XXXX-unsaferawpointer.md</a><br class=""><br class="">If you have opinions or suggestions on API syntax, please make yourself heard. You can jump straight to the naming discussion here:<br class=""><br class=""><a href="https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/XXXX-unsaferawpointer.md#variations-under-consideration" class="">https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/XXXX-unsaferawpointer.md#variations-under-consideration</a><br class=""><br class="">Of particular interest may be the API names for:<br class=""><br class="">- Memory allocation/deallocation: fairly fundamental to the language.<br class=""><br class="">- Unsafe casting from raw pointers to typed pointers. This is going to impact a lot of code that needs C interoperability.<br class=""><br class="">Keep in mind that we will make additive API improvements later for convenience. We want the fundamentals to be clear, explicit, and reasonably safe.<br class=""><br class="">-Andy<br class=""><br class=""><span id="cid:D2387E0D-D643-4BDF-9DDF-77B577E5275A@Home" class=""><XXXX-unsaferawpointer.md></span>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></blockquote></div></body></html>