<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="">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 class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><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 class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><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 class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><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 class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><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><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="">https://github.com/atrick/swift-evolution/blob/voidpointer/proposals/XXXX-unsaferawpointer.md#variations-under-consideration<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"><XXXX-unsaferawpointer.md></span>_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>