<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 13, 2017, at 6: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=""><div class=""><div class="">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" class="">https://github.com/kelvin13/maxpng</a> which makes extensive use of <span style="font-family:monospace,monospace" class="">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 class=""><br class=""><pre class=""><span class="gmail-pl-k">let</span> buffer <span class="gmail-pl-k">=</span> <span class="gmail-pl-c1">UnsafeMutableBufferPointer</span><span class="gmail-pl-k"><</span><span class="gmail-pl-c1">UInt8</span><span class="gmail-pl-k">></span>(<span class="gmail-pl-c1">start</span>: <span class="gmail-pl-c1">UnsafeMutablePointer</span><span class="gmail-pl-k"><</span><span class="gmail-pl-c1">UInt8</span><span class="gmail-pl-k">></span>.<span class="gmail-pl-c1">allocate</span>(<span class="gmail-pl-c1">capacity</span>: byteCount), <span class="gmail-pl-c1">count</span>: byteCount)
<span class="gmail-pl-k">defer</span>
{
buffer.<span class="gmail-pl-c1">baseAddress</span><span class="gmail-pl-k">?</span>.<span class="gmail-pl-c1">deallocate</span>(<span class="gmail-pl-c1">capacity</span>: buffer.<span class="gmail-pl-c1">count</span>)
}<br class=""><br class=""></pre><pre class=""><span style="font-family:arial,helvetica,sans-serif" class="">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 class=""><br class=""></span><span class="gmail-pl-c1">UnsafeMutablePointer</span>(<span class="gmail-pl-c1">mutating</span>: <span class="gmail-pl-c1">self</span>.<span class="gmail-pl-smi">zero_line</span>.<span class="gmail-pl-c1">baseAddress</span><span class="gmail-pl-k">!</span>).<span class="gmail-pl-c1">deallocate</span>(<span class="gmail-pl-c1">capacity</span>: <span class="gmail-pl-c1">self</span>.<span class="gmail-pl-smi">zero_line</span>.<span class="gmail-pl-c1">count</span>)<br class=""><br class=""></pre><pre class="">as <br class=""><br class=""><span class="gmail-pl-c1">UnsafeMutableBufferPointer(mutating: </span><span class="gmail-pl-c1">self</span>.<span class="gmail-pl-smi">zero_line).deallocate()</span></pre></div></div></div></div></blockquote><div><br class=""></div>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 class=""></div><div>-Andy</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jul 13, 2017 at 2:47 PM, Dave Abrahams via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
on Wed Jul 12 2017, Taylor Swift <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
<br class="">
> Hi all, I’ve written up a proposal to modify the unsafe pointer API for<br class="">
> greater consistency, safety, and ease of use.<br class="">
><br class="">
> ~~~<br class="">
><br class="">
> Swift currently offers two sets of pointer types — singular pointers such<br class="">
> as UnsafeMutablePointer, and vector (buffer) pointers such as UnsafeMutable<br class="">
</span>> *Buffer*Pointer. This implies a natural separation of tasks the two kinds<br class="">
<span class="">> of pointers are meant to do. For example, buffer pointers implement<br class="">
> Collection conformance, while singular pointers do not.<br class="">
><br class="">
> However, some aspects of the pointer design contradict these implied roles.<br class="">
> It is possible to allocate an arbitrary number of instances from a type<br class="">
> method on a singular pointer, but not from a buffer pointer. The result of<br class="">
> such an operation returns a singular pointer, even though a buffer pointer<br class="">
</span>> would be more appropriate to capture the information about the *number* of<br class="">
<span class="">> instances allocated. It’s possible to subscript into a singular pointer,<br class="">
> even though they are not real Collections. Some parts of the current design<br class="">
</span>> turn UnsafePointers into downright *Dangerous*Pointers, leading users to<br class="">
<span class="">> believe that they have allocated or freed memory when in fact, they have<br class="">
> not.<br class="">
><br class="">
> This proposal seeks to iron out these inconsistencies, and offer a more<br class="">
> convenient, more sensible, and less bug-prone API for Swift pointers.<br class="">
><br class="">
> <<a href="https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06" rel="noreferrer" target="_blank" class="">https://gist.github.com/<wbr class="">kelvin13/<wbr class="">a9c033193a28b1d4960a89b25fbffb<wbr class="">06</a>><br class="">
<br class="">
</span>I have no problem with this direction in principle; it sounds like a<br class="">
good idea. However, before affirming any particular design I would like<br class="">
to see the results of any such proposal applied to a fairly large body<br class="">
of code that uses Unsafe[XXX]Pointer today in diverse ways (such as the<br class="">
Swift standard library itself), to demonstrate that it does in fact<br class="">
improve the code in practice.<br class="">
<br class="">
Cheers,<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
--<br class="">
-Dave<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
</div></div></blockquote></div><br class=""></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>