<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 20, 2017 at 10:18 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><span class="gmail-"><blockquote type="cite"><div>On Aug 19, 2017, at 9:12 PM, Taylor Swift &lt;<a href="mailto:kelvin13ma@gmail.com" target="_blank">kelvin13ma@gmail.com</a>&gt; wrote:</div><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><span class="gmail-m_-9187988351253628752gmail-"><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra">and the other methods should take both an<span class="gmail-m_-9187988351253628752Apple-converted-space"> </span><i>offset</i><span class="gmail-m_-9187988351253628752Apple-converted-space"> </span>parameter instead of a count parameter:</div><div class="gmail_extra"><span style="font-family:monospace,monospace"><br></span></div><div class="gmail_extra"><span style="font-family:monospace,monospace">initialize(from:at:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace">assign(from:at:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace">moveInitialize(from:at:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace">moveAssign(from:at:)</span></div><div class="gmail_extra"><br></div><div class="gmail_extra">which provides maximum explicitness. This requires improvements to buffer pointer slicing though. But I’m not a fan of the mission creep that’s working into this proposal (i only originally wrote the thing to get<span class="gmail-m_-9187988351253628752Apple-converted-space"> </span><span style="font-family:monospace,monospace">allocate(capacity:)</span><span class="gmail-m_-9187988351253628752Apple-converted-space"> </span>and<span class="gmail-m_-9187988351253628752Apple-converted-space"> </span><span style="font-family:monospace,monospace">de<wbr>allocate()</span><span class="gmail-m_-9187988351253628752Apple-converted-space"> </span>into<span class="gmail-m_-9187988351253628752Apple-converted-space"> </span><span style="font-family:monospace,monospace">UnsafeMutableB<wbr>ufferPointer</span>!)</div></div></div></blockquote><br></span></div><div>I’m open to that, with source.count &lt;= self.count + index. They are potentially ambiguous (the `at` could refer to a source index) but consistent with the idea that this API is for copying an entire source buffer into a slice of the destination buffer. Again, we need to find real code that benefits from this, but I expect the stdlib could use these.</div></div></blockquote></div></div></div></blockquote><div><br></div></span><div><div>In case that typo wasn’t obvious, we actually want the precondition: `offset + source.count &lt;= self.count` (your latest proposal draft is correct).</div><div><br></div></div><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">The more I think the more I believe using<span class="gmail-m_-9187988351253628752Apple-converted-space"> </span><span style="font-family:monospace,monospace">from:at:</span><span class="gmail-m_-9187988351253628752Apple-converted-space"> </span>is the right approach. The only problem is that it would have to be written as a generic on<span class="gmail-m_-9187988351253628752Apple-converted-space"> </span><span style="font-family:monospace,monospace">Collection</span>or<span class="gmail-m_-9187988351253628752Apple-converted-space"> </span><span style="font-family:monospace,monospace">Sequence</span><span class="gmail-m_-9187988351253628752Apple-converted-space"> </span>to avoid having to provide up to 4 overloads for each operation, since we would want these to work well with buffer slices as well as buffers themselves. That puts them uncomfortably close to the turf of the existing buffer pointer<span class="gmail-m_-9187988351253628752Apple-converted-space"> </span><span style="font-family:monospace,monospace">Sequence</span><span class="gmail-m_-9187988351253628752Apple-converted-space"> </span>API though.<br></div></div></blockquote><div><br></div><div><div>It would have to be a generic method taking a RandomAccessCollection. Calling that would rely on tricky type inference. For now, I prefer the explicitly typed API in your current proposal.</div><div><br></div></div></div><span class="gmail-"><div><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">Or we could make<span class="gmail-m_-9187988351253628752Apple-converted-space"> </span><span style="font-family:monospace,monospace">UnsafeMutableBufferPointe<wbr>r</span><span class="gmail-m_-9187988351253628752Apple-converted-space"> </span>its own slice type. Right now<span class="gmail-m_-9187988351253628752Apple-converted-space"> </span><span style="font-family:monospace,monospace">MutableRandomAccessSlice&lt;<wbr>UnsafeMutableBufferPointer&lt;<wbr>Element&gt;&gt;</span><span class="gmail-m_-9187988351253628752Apple-converted-space"> </span>takes up 4 words of storage when it really only needs two.</div></div></blockquote></div><div><br></div></span>A slice needs to be a separate type because of the indexing semantics:<br><div><a href="https://github.com/apple/swift-evolution/commit/c8165b41b188c3d095425a0b4636fcf299ee9036" target="_blank">https://github.com/apple/<wbr>swift-evolution/commit/<wbr>c8165b41b188c3d095425a0b4636fc<wbr>f299ee9036</a></div><div><br></div><div><div>Note that it&#39;s actually a feature that Subsequence refers back to its original buffer. If we cared enough, we could define a buffer slice type that exposes most of the buffer API. I just don&#39;t think we need to worry about that level of convenience yet, especially with you adding the `at:` labels. I&#39;m fine if developers resort to `init(rebasing:)` in rare cases. Again, once we have a safe move-only or reference counted buffer type, that will be the better choice for Swift APIs. For now, this is still largely driven by C interop.</div></div></div></blockquote><div><br></div><div>a method like `buffer.segment(0 ..&lt; 5)` or something which would avoid constructing the slice type (and save typing that long `UnsafeMutableBufferPointer(rebasing:)` name) like that would be nice . but that’s just sugar and not very important if you ask me<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>I like this proposal as it stands!</div><div><a href="https://github.com/kelvin13/swift-evolution/blob/9d305ced7b82b9cf5854b55b3f0d08952853d046/proposals/0184-improved-pointers.md" target="_blank">https://github.com/kelvin13/<wbr>swift-evolution/blob/<wbr>9d305ced7b82b9cf5854b55b3f0d08<wbr>952853d046/proposals/0184-<wbr>improved-pointers.md</a></div><div><br></div><div>-Andy</div></div></blockquote><div> </div></div></div><div class="gmail_extra">I’ll try to get an updated implementation out in the next few days<br></div></div>