<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 Aug 19, 2017, at 9:12 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><div class=""><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; -webkit-text-stroke-width: 0px;"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div class=""><span class="gmail-"><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">and the other methods should take both an<span class="Apple-converted-space"> </span><i class="">offset</i><span class="Apple-converted-space"> </span>parameter instead of a count parameter:</div><div class="gmail_extra"><span style="font-family: monospace, monospace;" class=""><br class=""></span></div><div class="gmail_extra"><span style="font-family: monospace, monospace;" class="">initialize(from:at:)</span></div><div class="gmail_extra"><span style="font-family: monospace, monospace;" class="">assign(from:at:)</span></div><div class="gmail_extra"><span style="font-family: monospace, monospace;" class="">moveInitialize(from:at:)</span></div><div class="gmail_extra"><span style="font-family: monospace, monospace;" class="">moveAssign(from:at:)</span></div><div class="gmail_extra"><br class=""></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="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">allocate(capacity:)</span><span class="Apple-converted-space"> </span>and<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">deallocate()</span><span class="Apple-converted-space"> </span>into<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">UnsafeMutableBufferPointer</span>!)</div></div></div></blockquote><br class=""></span></div><div class="">I’m open to that, with source.count <= 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 class=""></div><div><div>In case that typo wasn’t obvious, we actually want the precondition: `offset + source.count <= self.count` (your latest proposal draft is correct).</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><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; -webkit-text-stroke-width: 0px;">The more I think the more I believe using<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">from:at:</span><span class="Apple-converted-space"> </span>is the right approach. The only problem is that it would have to be written as a generic on<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">Collection</span>or<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">Sequence</span><span class="Apple-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="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">Sequence</span><span class="Apple-converted-space"> </span>API though.<br class=""></div></div></blockquote><div><br class=""></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 class=""><br class=""></div></div></div><div><blockquote type="cite" class=""><div class=""><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; -webkit-text-stroke-width: 0px;">Or we could make<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">UnsafeMutableBufferPointer</span><span class="Apple-converted-space"> </span>its own slice type. Right now<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">MutableRandomAccessSlice<UnsafeMutableBufferPointer<Element>></span><span class="Apple-converted-space"> </span>takes up 4 words of storage when it really only needs two.</div></div></blockquote></div><div class=""><br class=""></div>A slice needs to be a separate type because of the indexing semantics:<br class=""><div class=""><a href="https://github.com/apple/swift-evolution/commit/c8165b41b188c3d095425a0b4636fcf299ee9036" class="">https://github.com/apple/swift-evolution/commit/c8165b41b188c3d095425a0b4636fcf299ee9036</a></div><div class=""><br class=""></div><div class=""><div class="">Note that it'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't think we need to worry about that level of convenience yet, especially with you adding the `at:` labels. I'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 class=""><br class=""></div><div class="">I like this proposal as it stands!</div><div class=""><a href="https://github.com/kelvin13/swift-evolution/blob/9d305ced7b82b9cf5854b55b3f0d08952853d046/proposals/0184-improved-pointers.md" class="">https://github.com/kelvin13/swift-evolution/blob/9d305ced7b82b9cf5854b55b3f0d08952853d046/proposals/0184-improved-pointers.md</a></div><div class=""><br class=""></div><div class="">-Andy</div></body></html>