<div dir="ltr">done: <a href="https://github.com/apple/swift-evolution/pull/744">https://github.com/apple/swift-evolution/pull/744</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 23, 2017 at 1:56 PM, 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">Kelvin,<div><br></div><div>Please resubmit a clean swift-evolution PR now. I personally think this is ready for formal review given that all feedback was positive and all issues brought up during review have been addressed.</div><div><br></div><div>-Andy</div><div><div class="h5"><div><br><div><blockquote type="cite"><div>On Aug 22, 2017, at 12:59 PM, Michael Ilseman <<a href="mailto:milseman@apple.com" target="_blank">milseman@apple.com</a>> wrote:</div><br class="m_7964732650000069980Apple-interchange-newline"><div><div style="word-wrap:break-word"><div>This is an excellent, thoroughly thought out, and well written proposal! I’m eager to see these improvements land.</div><div><br></div><br><div><blockquote type="cite"><div>On Aug 22, 2017, at 11:33 AM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_7964732650000069980Apple-interchange-newline"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 22, 2017 at 2:35 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><span class="m_7964732650000069980gmail-"><blockquote type="cite"><div>On Aug 21, 2017, at 10:59 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>> wrote:</div><br class="m_7964732650000069980gmail-m_2316532995978433485Apple-interchange-newline"><div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div>Sorry to bring this up again, but I was not able to defend the addition of `<a href="http://unsafemutablebufferpointer.de/" target="_blank">UnsafeMutableBufferPointer.de</a><wbr>initialize()`. It is incorrect for the typical use case and doesn't appear to solve any important use case. The *only* fully initializing method is `initialize(repeating:)`, but that will usually be used for trivial values, which should not be deinitialized. It's preferable for the user to explicitly deinitialize just the segments that they know were initialized, which can be done on the base pointer. The only benefit in having a `deinitialize` on the buffer is to communicate to users who see the `initialize` API for the first time that it is their responsibility to deinitialize if the type requires it. To that end, we could add a `deinitialize(at:count:)` method, communicating the symmetry with `initialize(at:from:). Naturally `index + count <= self.count`.</div><div><br></div><div>-Andy</div></div></div></blockquote><div><br></div><div>I don’t agree with this. If `<span style="font-family:monospace,monospace">deinitialize()</span>` is a problem because it deinitializes the entire buffer, so are `<span style="font-family:monospace,monospace">moveAssign</span>` and `<span style="font-family:monospace,monospace">moveInitialize</span>`. They all assume the released buffer operand is fully initialized. `<span style="font-family:monospace,monospace">deinitialize()</span>` has just as much use as the other full-buffer releasing methods. Just take the image buffer example there<span class="m_7964732650000069980gmail-m_2316532995978433485Apple-converted-space"> </span><br></div></div></div></div></blockquote><div><br></div></span><div>`moveAssign` and `moveInitialize` assume that the sub-buffer being moved from is fully initialized. That’s already obvious because the user is asking to move source.count elements. I don’t see any use cases where it would pose a problem. If the user is moving out of a partially initialized buffer, they have already to sliced (and unfortunately rebased) the buffer. OTOH `deinitialize` is incorrect for normal use cases. I don’t see any practical analogy between those APIs.</div><span class="m_7964732650000069980gmail-"><blockquote type="cite"><div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div><pre><span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">let</span> pixels<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">:</span><span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">Int</span> <span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">=</span> scanlines.<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">map</span>{ <span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">$0</span>.<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">count</span> }.<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">reduce</span>(<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">0</span>, <span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">+</span>)
<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">var</span> image <span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">=</span> <span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">UnsafeMutableBufferPointer</span><span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k"><</span>Pix<wbr>el<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">></span>.<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">allocate</span>(<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">capacity</span>: pixels)
<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">var</span> filled<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">:</span><span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">Int</span> <span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">=</span> <span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">0</span>
<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">for</span> scanline<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">:</span><span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">UnsafeMutableBufferPo<wbr>inter</span><span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k"><</span>Pixel<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">></span> <span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">in</span> scanlines
{
image.<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">moveInitialize</span>(<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">at</span>: filled, <span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">from</span>: scanline)
filled <span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-k">+=</span> scanline.<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">count</span>
}
image.<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">deinitialize</span>()</pre></div></div></div></div></blockquote></span><div>We don’t want developers to do this. Instead we want to see an explicitly named association between the number of items initialized and deinitialized:</div><div><br></div><div>image.deinitialize(at: 0, count: filled)</div><div><br></div><div>Flipping this around, it could be even more common to be writing into a larger than necessary buffer (pixels > filled). If we’re providing auto-slicing initializers, then deinitialization should follow the same approach, rather than:</div><div><br></div><div>UnsafeMutableBufferPointer(reb<wbr>asing: image[0, filled]).deinitialize()</div><span class="m_7964732650000069980gmail-"><blockquote type="cite"><div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div><pre>image.<span class="m_7964732650000069980gmail-m_2316532995978433485gmail-pl-c1">deallocate</span>()<br><br></pre><pre><span style="font-family:arial,helvetica,sans-serif">and replace `<span style="font-family:monospace,monospace">Pixel</span>` with a class type like `<span style="font-family:monospace,monospace">UIButton</span>`.</span><br></pre></div></div>And `<span style="font-family:monospace,monospace">deinitialize(at:count:)</span>` is bad because you’re asking for a count on a buffer method. `<span style="font-family:monospace,monospace">moveAssign</span>` and `<span style="font-family:monospace,monospace">moveInitialize</span>` can take range parameters because they each have a second operand that supplies the count number. `<span style="font-family:monospace,monospace">deinitialize</span>` doesn’t. That means calls could end up looking like<span class="m_7964732650000069980gmail-m_2316532995978433485Apple-converted-space"> </span><br></div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:monospace,monospace">buffer.deinitialize(at: 0, count: buffer.count)</span></div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div class="gmail_extra" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">which is exactly what we were trying to avoid in the first place.</div></div></blockquote></span></div><br><div>But there is no value in avoiding the `count` argument here. That’s not a valid motivation for introducing `deinitialize` on a buffer, and we’d be better off not introducing it at all.</div><div><br></div><div>The only valid motivation I can come up with for introducing `deinitialize` on buffer is to remind developers who are only looking at the buffer API (and not the plain pointer API) that it’s their responsibility to manually deinitialize (it doesn’t automatically happen on deallocation or destruction).</div><div><br></div><div>-Andy</div><div><br></div></div></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I replaced <span style="font-family:monospace,monospace">UnsafeMutableBufferPointer.<wbr>deinitialize()</span> with <span style="font-family:monospace,monospace">UnsafeMutableBufferPointer.<wbr>deinitialize(at:count:)</span></div></div>
</div></blockquote></div><br></div></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div>