<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=""><div class="">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 class=""><div><blockquote type="cite" class=""><div class="">On Jul 12, 2017, at 12:16 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=""><p class="">Hi all, I’ve written up a proposal to modify the unsafe pointer API for greater consistency, safety, and ease of use.</p><p class="">~~~<br class=""></p><p class="">Swift currently offers two sets of pointer types — singular pointers such as <code class="">UnsafeMutablePointer</code>, and vector (buffer) pointers such as <code class="">UnsafeMutable</code><strong class=""><code class="">Buffer</code></strong><code class="">Pointer</code>. This implies a natural separation of tasks the two kinds of pointers are meant to do. For example, buffer pointers implement <code class="">Collection</code> conformance, while singular pointers do not.</p><p class="">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 class="">number</em> of instances allocated. It’s possible to subscript into a singular pointer, even though they are not real <code class="">Collection</code>s. Some parts of the current design turn UnsafePointers into downright <em class="">Dangerous</em>Pointers, leading users to believe that they have allocated or freed memory when in fact, they have not.</p><p class="">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 class=""><<a href="https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06" class="">https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06</a>></p><p class="">~~~<br class=""></p></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>