<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 14, 2017 at 12:29 AM, Andrew Trick <span dir="ltr">&lt;<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>&gt;</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"><br><div><span class=""><blockquote type="cite"><div>On Jul 13, 2017, at 6:16 PM, Taylor Swift via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_-2949308447209051328Apple-interchange-newline"><div><div dir="ltr"><div><div>I am not very familiar with the inner workings of the standard library, however I maintain a few libraries which make extensive use of Swift pointers, such as <a href="https://github.com/kelvin13/maxpng" target="_blank">https://github.com/kelvin13/<wbr>maxpng</a> which makes extensive use of <span style="font-family:monospace,monospace">Unsafe_____Pointer</span>s. I also write a lot of code that interfaces with C APIs like Cairo and OpenGL. Most of the ideas in the original proposal came from me dealing with the current Swift pointer APIs in my own code. For example I find myself writing this bit of code <br><br><pre><span class="m_-2949308447209051328gmail-pl-k">let</span> buffer <span class="m_-2949308447209051328gmail-pl-k">=</span> <span class="m_-2949308447209051328gmail-pl-c1">UnsafeMutableBufferPointer</span><span class="m_-2949308447209051328gmail-pl-k">&lt;</span><span class="m_-2949308447209051328gmail-pl-c1">UIn<wbr>t8</span><span class="m_-2949308447209051328gmail-pl-k">&gt;</span>(<span class="m_-2949308447209051328gmail-pl-c1">start</span>: <span class="m_-2949308447209051328gmail-pl-c1">UnsafeMutablePointer</span><span class="m_-2949308447209051328gmail-pl-k">&lt;</span><span class="m_-2949308447209051328gmail-pl-c1">UInt8</span><span class="m_-2949308447209051328gmail-pl-k">&gt;</span>.<span class="m_-2949308447209051328gmail-pl-c1">al<wbr>locate</span>(<span class="m_-2949308447209051328gmail-pl-c1">capacity</span>: byteCount), <span class="m_-2949308447209051328gmail-pl-c1">count</span>: byteCount)
<span class="m_-2949308447209051328gmail-pl-k">defer</span>
{
    buffer.<span class="m_-2949308447209051328gmail-pl-c1">baseAddress</span><span class="m_-2949308447209051328gmail-pl-k">?</span>.<span class="m_-2949308447209051328gmail-pl-c1">deallocate</span><wbr>(<span class="m_-2949308447209051328gmail-pl-c1">capacity</span>: buffer.<span class="m_-2949308447209051328gmail-pl-c1">count</span>)
}<br><br></pre><pre><span style="font-family:arial,helvetica,sans-serif">far more than I would like to. While this proposal doesn’t solve every problem with Swift pointers — for example, we need a UMBP initializer that takes an immutable buffer pointer before we are really able to write a lot of examples more concisely, it takes us a great deal closer to being able to write things like <br><br></span><span class="m_-2949308447209051328gmail-pl-c1">UnsafeMutablePointer</span>(<span class="m_-2949308447209051328gmail-pl-c1">mutating</span>: <span class="m_-2949308447209051328gmail-pl-c1">self</span>.<span class="m_-2949308447209051328gmail-pl-smi">zero_line</span>.<span class="m_-2949308447209051328gmail-pl-c1">baseAddress</span><span class="m_-2949308447209051328gmail-pl-k">!</span>).<span class="m_-2949308447209051328gmail-pl-c1">d<wbr>eallocate</span>(<span class="m_-2949308447209051328gmail-pl-c1">capacity</span>: <span class="m_-2949308447209051328gmail-pl-c1">self</span>.<span class="m_-2949308447209051328gmail-pl-smi">zero_line</span>.<span class="m_-2949308447209051328gmail-pl-c1">count</span>)<br><br></pre><pre>as <br><br><span class="m_-2949308447209051328gmail-pl-c1">UnsafeMutableBufferPointer(<wbr>mutating: </span><span class="m_-2949308447209051328gmail-pl-c1">self</span>.<span class="m_-2949308447209051328gmail-pl-smi">zero_line).deallocate()</span></pre></div></div></div></div></blockquote><div><br></div></span>You should not need to do this at all. A pointer does not need to be mutable to deallocate the memory. That’s a bug in the UnsafePointer API.</div><div><br></div><div>-Andy</div><div><div class="h5"><div><br></div></div></div></div></blockquote><div><br></div><div>I think this falls under “convenience methods that would be really nice to have but should probably go in a separate proposal”. <br></div><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"><div><blockquote type="cite"><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 13, 2017 at 2:47 PM, Dave Abrahams via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
on Wed Jul 12 2017, Taylor Swift &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt; Hi all, I’ve written up a proposal to modify the unsafe pointer API for<br>
&gt; greater consistency, safety, and ease of use.<br>
&gt;<br>
&gt; ~~~<br>
&gt;<br>
&gt; Swift currently offers two sets of pointer types — singular pointers such<br>
&gt; as UnsafeMutablePointer, and vector (buffer) pointers such as UnsafeMutable<br>
</span>&gt; *Buffer*Pointer. This implies a natural separation of tasks the two kinds<br>
<span>&gt; of pointers are meant to do. For example, buffer pointers implement<br>
&gt; Collection conformance, while singular pointers do not.<br>
&gt;<br>
&gt; However, some aspects of the pointer design contradict these implied roles.<br>
&gt; It is possible to allocate an arbitrary number of instances from a type<br>
&gt; method on a singular pointer, but not from a buffer pointer. The result of<br>
&gt; such an operation returns a singular pointer, even though a buffer pointer<br>
</span>&gt; would be more appropriate to capture the information about the *number* of<br>
<span>&gt; instances allocated. It’s possible to subscript into a singular pointer,<br>
&gt; even though they are not real Collections. Some parts of the current design<br>
</span>&gt; turn UnsafePointers into downright *Dangerous*Pointers, leading users to<br>
<span>&gt; believe that they have allocated or freed memory when in fact, they have<br>
&gt; not.<br>
&gt;<br>
&gt; This proposal seeks to iron out these inconsistencies, and offer a more<br>
&gt; convenient, more sensible, and less bug-prone API for Swift pointers.<br>
&gt;<br>
&gt; &lt;<a href="https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06" rel="noreferrer" target="_blank">https://gist.github.com/kelvi<wbr>n13/a9c033193a28b1d4960a89b25f<wbr>bffb06</a>&gt;<br>
<br>
</span>I have no problem with this direction in principle; it sounds like a<br>
good idea.  However, before affirming any particular design I would like<br>
to see the results of any such proposal applied to a fairly large body<br>
of code that uses Unsafe[XXX]Pointer today in diverse ways (such as the<br>
Swift standard library itself), to demonstrate that it does in fact<br>
improve the code in practice.<br>
<br>
Cheers,<br>
<span class="m_-2949308447209051328HOEnZb"><font color="#888888"><br>
--<br>
-Dave<br>
</font></span><div class="m_-2949308447209051328HOEnZb"><div class="m_-2949308447209051328h5"><br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>
______________________________<wbr>_________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div>