<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=""><br class=""></div></blockquote></div></div></div></div></blockquote></div></div></div></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">Would you mind adding a deallocate method to (nonmutable) UnsafePointer/UnsafeBufferPointer to take care of</div><div class=""><div class="">[SR-3309](<a href="https://bugs.swift.org/browse/SR-3309" class="">https://bugs.swift.org/browse/SR-3309</a>)?</div></div><div class=""><br class=""></div><div class="">There’s simply nothing in the memory model that requires mutable memory for deallocation.</div><div class=""><br class=""></div><div class="">It fits right in with this proposal and hardly seems worth a separate one.</div><div class=""><br class=""></div><div class="">-Andy</div><div class=""><br class=""></div></body></html>