<div dir="ltr">Should the immutable buffer pointer types also get deallocate()?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 7:55 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br><div><blockquote type="cite"><div>On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_6565581470495875784Apple-interchange-newline"><div><div dir="ltr">Implementation is here: <a href="https://github.com/apple/swift/pull/11464" target="_blank">https://github.com/apple/<wbr>swift/pull/11464</a><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift <span dir="ltr"><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</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 dir="ltr">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">Sequence</span>s at the same time as this actually makes the design a bit simpler.<br><div><<a href="https://gist.github.com/kelvin13/5edaf43dcd3d6d9ed24f303fc941214c" target="_blank">https://gist.github.com/kelvi<wbr>n13/5edaf43dcd3d6d9ed24f303fc9<wbr>41214c</a>><br><i><br></i><div style="margin-left:40px"><i>The <a href="https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907" target="_blank">previous version</a> of this document ignored the generic initialization methods on <code>UnsafeMutableBufferPointer</code> and <code>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="m_6565581470495875784gmail-HOEnZb"><div class="m_6565581470495875784gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 8, 2017 at 12:52 PM, Taylor Swift <span dir="ltr"><<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</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 dir="ltr">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><<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md" target="_blank">https://github.com/apple/swif<wbr>t-evolution/blob/master/propos<wbr>als/0184-improved-pointers.md</a>><br><br></div></blockquote></div></div></div></div></blockquote></div></div></div></div></div></blockquote></div><br><div><br></div></div></div><div>Would you mind adding a deallocate method to (nonmutable) UnsafePointer/<wbr>UnsafeBufferPointer to take care of</div><div><div>[SR-3309](<a href="https://bugs.swift.org/browse/SR-3309" target="_blank">https://bugs.swift.<wbr>org/browse/SR-3309</a>)?</div></div><div><br></div><div>There’s simply nothing in the memory model that requires mutable memory for deallocation.</div><div><br></div><div>It fits right in with this proposal and hardly seems worth a separate one.</div><div><br></div><div>-Andy</div><div><br></div></div></blockquote></div><br></div>