<div dir="ltr">I’ve drafted a new version of the unsafe pointer proposal based on feedback I’ve gotten from this thread. You can read it <a href="https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907">here</a>.<br><br>~~~<br><p>Swift’s pointer types are an important interface for low-level memory
manipulation, but the current API design is not very safe, consistent,
or convenient. Many memory methods demand a <code>capacity:</code> or <code>count:</code>
argument, forcing the user to manually track the size of the memory
block, even though most of the time this is either unnecessary, or
redundant as buffer pointers track this information natively. In some
places, this design turns UnsafePointers into outright <em>Dangerous</em>Pointers, leading users to believe that they have allocated or freed memory when in fact, they have not.</p>
<p>The current API suffers from inconsistent naming, poor usage of
default argument values, missing methods, and excessive verbosity, and
encourages excessively unsafe programming practices. 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>The <a href="https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06">previous draft</a>
of this proposal was relatively source-breaking, calling for a
separation of functionality between singular pointer types and vector
(buffer) pointer types. This proposal instead separates functionality
between internally-tracked length pointer types and externally-tracked
length pointer types. This results in an equally elegant API with about one-third less surface area.</p><p><<a href="https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907">https://gist.github.com/kelvin13/1b8ae906be23dff22f7a7c4767f0c907</a>><br></p><p>~~~<br></p></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 12, 2017 at 3:16 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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/<wbr>kelvin13/<wbr>a9c033193a28b1d4960a89b25fbffb<wbr>06</a>></p><p>~~~<br></p></div>
</blockquote></div><br></div>