<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I agree with most of this proposal. Removing the subscript bugs me, but pointer arithmetic currently takes the stride of the type into account, so I don’t necessarily have a problem with that.<div class=""><br class=""></div><div class="">I would really appreciate <font face="Menlo" class="">Unsafe*BufferPointer.allocate(count:)</font>, and I definitely think the sized deallocators are actively dangerous unless the arguments are used. I fully support their removal.<div><br class=""><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=""></div></body></html>