<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 Aug 15, 2017, at 9:47 PM, Taylor Swift 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 dir="ltr" class="">Implementation is here: <a href="https://github.com/apple/swift/pull/11464" class="">https://github.com/apple/swift/pull/11464</a><br class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift <span dir="ltr" class=""><<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">I’ve revised the proposal based on what I learned from trying to implement these changes. I think it’s worth tacking the existing methods that take <span style="font-family:monospace,monospace" class="">Sequence</span>s at the same time as this actually makes the design a bit simpler.<br class=""><div class=""><<a href="https://gist.github.com/kelvin13/5edaf43dcd3d6d9ed24f303fc941214c" target="_blank" class="">https://gist.github.com/<wbr class="">kelvin13/<wbr class="">5edaf43dcd3d6d9ed24f303fc94121<wbr class="">4c</a>><br class=""><i class=""><br class=""></i><div style="margin-left:40px" class=""><i class="">The <a href="https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907" target="_blank" class="">previous version</a> of this document ignored the generic initialization methods on <code class="">UnsafeMutableBufferPointer</code> and <code class="">UnsafeMutableRawBufferPointer</code>,
leaving them to be overhauled at a later date, in a separate proposal.
Instead, this version of the proposal leverages those existing methods
to inform a more compact API design which has less surface area, and is
more future-proof since it obviates the need to design and add another
(redundant) set of protocol-oriented pointer APIs later.</i></div></div></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Aug 8, 2017 at 12:52 PM, Taylor Swift <span dir="ltr" class=""><<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is ready for community review, and I encourage everyone to look it over and provide feedback. Thank you!<br class=""><<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md" target="_blank" class="">https://github.com/apple/swif<wbr class="">t-evolution/blob/master/propos<wbr class="">als/0184-improved-pointers.md</a>><br class=""></div></blockquote></div></div></div></div></blockquote></div></div></div></div></div></blockquote></div><div class=""><br class=""></div>Thanks for continuing to improve this proposal. It’s in great shape now.<div class=""><br class=""></div><div class="">Upon rereading it today I have to say I strongly object to the `count = 1` default in the following two cases:<div class=""><div class=""><br class=""></div><div class="">+ UnsafeMutablePointer.withMemoryRebound(to: count: Int = 1)</div><div class="">+ UnsafeMutableRawPointer.bindMemory<T>(to:T.Type, count:Int = 1)</div><div class=""> -> UnsafeMutablePointer<T></div><div class=""><br class=""></div><div class="">To aid understanding, it needs to be clear at the call-site that binding memory only applies to the specified number of elements. It's a common mistake for users to think they can obtain a pointer to a different type, then use that pointer as a base to access other elements. These APIs are dangerous expert interfaces. We certainly don't want to make their usage more concise at the expense of clarity.</div><div class=""><br class=""></div><div class="">In general, I think there's very little value in the `count=1` default, and it creates potential confusion on the caller side between the `BufferPointer` API and the `Pointer` API. For example:</div><div class=""><br class=""></div><div class="">+ initialize(repeating:Pointee, count:Int = 1)</div><div class=""><br class=""></div><div class="">Seeing `p.initialize(repeating: x)`, the user may think `p` refers to the buffer instead of a pointer into the buffer and misunderstand the behavior.</div><div class=""><br class=""></div><div class="">+ UnsafeMutablePointer.deinitialize(count: Int = 1)</div><div class=""><br class=""></div><div class="">Again, `p.deinitialize()` looks to me like it might be deinitializing an entire buffer.</div><div class=""><br class=""></div><div class="">If the `count` label is always explicit, then there's a clear distinction between the low-level `pointer` APIs and the `buffer` APIs.</div><div class=""><br class=""></div><div class="">The pointer-to-single-element case never seemed interesting enough to me to worry about making convenient. If I'm wrong about that, is there some real-world code you can point to where the count=1 default significantly improves clarity?</div></div><div class=""><br class=""></div></div><div class="">-Andy</div></body></html>