<div dir="ltr"><div>Hi all, i’ve put out a new revision of the proposal which addresses Michael’s point about dealing with the memorystate APIs along with the allocation and deallocation API. I didn’t really think about fixing the memorystate functions originally, but on closer inspection, they are almost as problematic as the memory allocation API and deserve a closer look. <br><br></div>Here’s a new version of the proposal with revisions<br><<a href="https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06">https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06</a>><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 6:46 PM, Taylor Swift via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr">I originally thought that would be too many changes for one proposal but if y’all think it’s a good idea to deal with those functions too I’m happy to add it to the proposal!<br></div></span><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Jul 12, 2017 at 5:07 PM, Michael Ilseman <span dir="ltr"><<a href="mailto:milseman@apple.com" target="_blank">milseman@apple.com</a>></span> wrote:<br></span><div><div class="h5"><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>If you’re considering moving allocate/deallocate to Unsafe*BufferPointer, then you probably also want to consider doing the same for initialize, deinitialize, and various move functions as well.</div><br><div><blockquote type="cite"><div><div class="m_4292346717077586708h5"><div>On Jul 12, 2017, at 12:16 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_4292346717077586708m_-1037881327694107798Apple-interchange-newline"></div></div><div><div><div class="m_4292346717077586708h5"><div dir="ltr"><p>Hi all, I’ve written up a proposal to modify the unsafe pointer API for greater consistency, safety, and ease of use.</p><p>~~~<br></p><p>Swift currently offers two sets of pointer types — singular pointers such as <code>UnsafeMutablePointer</code>, and vector (buffer) pointers such as <code>UnsafeMutable</code><strong><code>Buffer</code></strong><code>Pointer</code>. This implies a natural separation of tasks the two kinds of pointers are meant to do. For example, buffer pointers implement <code>Collection</code> conformance, while singular pointers do not.</p><p>However, some aspects of the pointer design contradict these implied
roles. It is possible to allocate an arbitrary number of instances from a
type method on a singular pointer, but not from a buffer pointer. The
result of such an operation returns a singular pointer, even though a
buffer pointer would be more appropriate to capture the information
about the <em>number</em> of instances allocated. It’s possible to subscript into a singular pointer, even though they are not real <code>Collection</code>s. Some parts of the current design turn UnsafePointers into downright <em>Dangerous</em>Pointers, leading users to believe that they have allocated or freed memory when in fact, they have not.</p><p>This proposal seeks to iron out these inconsistencies, and offer a
more convenient, more sensible, and less bug-prone API for Swift
pointers.</p><p><<a href="https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06" target="_blank">https://gist.github.com/kelvi<wbr>n13/a9c033193a28b1d4960a89b25f<wbr>bffb06</a>></p><p>~~~<br></p></div></div></div>
______________________________<wbr>_________________<span><br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></blockquote></div></div></div><br></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>