<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"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></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 <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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"><</span><span class="m_-2949308447209051328gmail-pl-c1">UIn<wbr>t8</span><span class="m_-2949308447209051328gmail-pl-k">></span>(<span class="m_-2949308447209051328gmail-pl-c1">start</span>: <span class="m_-2949308447209051328gmail-pl-c1">UnsafeMutablePointer</span><span class="m_-2949308447209051328gmail-pl-k"><</span><span class="m_-2949308447209051328gmail-pl-c1">UInt8</span><span class="m_-2949308447209051328gmail-pl-k">></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"><<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><br>
on Wed Jul 12 2017, Taylor Swift <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
> Hi all, I’ve written up a proposal to modify the unsafe pointer API for<br>
> greater consistency, safety, and ease of use.<br>
><br>
> ~~~<br>
><br>
> Swift currently offers two sets of pointer types — singular pointers such<br>
> as UnsafeMutablePointer, and vector (buffer) pointers such as UnsafeMutable<br>
</span>> *Buffer*Pointer. This implies a natural separation of tasks the two kinds<br>
<span>> of pointers are meant to do. For example, buffer pointers implement<br>
> Collection conformance, while singular pointers do not.<br>
><br>
> However, some aspects of the pointer design contradict these implied roles.<br>
> It is possible to allocate an arbitrary number of instances from a type<br>
> method on a singular pointer, but not from a buffer pointer. The result of<br>
> such an operation returns a singular pointer, even though a buffer pointer<br>
</span>> would be more appropriate to capture the information about the *number* of<br>
<span>> instances allocated. It’s possible to subscript into a singular pointer,<br>
> even though they are not real Collections. Some parts of the current design<br>
</span>> turn UnsafePointers into downright *Dangerous*Pointers, leading users to<br>
<span>> believe that they have allocated or freed memory when in fact, they have<br>
> not.<br>
><br>
> This proposal seeks to iron out these inconsistencies, and offer a more<br>
> convenient, more sensible, and less bug-prone API for Swift pointers.<br>
><br>
> <<a href="https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06" rel="noreferrer" target="_blank">https://gist.github.com/kelvi<wbr>n13/a9c033193a28b1d4960a89b25f<wbr>bffb06</a>><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>