<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 6:42 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick <span dir="ltr" class=""><<a href="mailto:atrick@apple.com" target="_blank" class="">atrick@apple.com</a>></span> wrote:<br class=""><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;" class=""><br class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class="">On Aug 19, 2017, at 6:16 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" target="_blank" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="gmail-m_321540164580745063Apple-interchange-newline"><div class=""><div dir="ltr" class="">What you’re describing is basically an earlier version of the proposal which had a slightly weaker precondition (source >= destination) than yours (source == destination). That one basically ignored the Sequence methods at the expense of greater API surface area.<br class=""></div></div></blockquote><div class=""><br class=""></div></span><div class="">The Sequence methods don’t provide the simpler, more convenient form of initialization/<wbr class="">deinitialization that I thought you wanted. I see two reasonable options.</div><div class=""><br class=""></div><div class="">1. Don’t provide any new buffer initialization/<wbr class="">deinitialization convenience. i.e. drop UsafeMutableBufferPointer moveInitialize, moveAssign, and deinitialize from your proposal.</div><div class=""><br class=""></div><div class="">2. Provide the full set of convenience methods: initialize, assign, moveInitialize, and moveAssign assuming self.count==source.count. And provide deinitialize() to be used only in conjunction with those new initializers.</div><div class=""><br class=""></div><div class="">The question is really whether those new methods are going to significantly simplify your code. If not, #1 is the conservative choice. Don't provide convenience which could be misused. Put off solving that problem until we can design a new move-only buffer type that tracks partially initialized state.</div><div class=""><br class=""></div><div class="">-Andy <br class=""></div></div><br class=""></div></blockquote></div></div><br class="">I’m not sure the answer is to just omit methods from <span style="font-family:monospace,monospace" class="">UnsafeMutableBufferPointer</span> since most of the original complaints circulated around having to un-nil <span style="font-family:monospace,monospace" class="">baseAddress</span> to do anything with them.<br class=""></div></div></blockquote><div><br class=""></div><div>I know un-nil’ing baseAddress is horrible, but I don’t think working around that is an important goal yet. Eventually there will be a much safer, more convenient mechanism for manual allocation that doesn’t involve “pointers". I also considered adding API surface to UnsafeMutableBufferPointer.Slice, but that’s beyond what we should do now and may also become irrelevant when we have a more sophisticated buffer type. </div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">What if only unary methods should be added to <span style="font-family:monospace,monospace" class="">UnsafeMutableBufferPointer</span> without <span style="font-family:monospace,monospace" class="">count:</span>, meaning:<div class="gmail_extra"><br class=""></div><div class="gmail_extra"><span style="font-family:monospace,monospace" class="">initialize(repeating:)</span></div></div></div></blockquote><div><br class=""></div>I actually have no problem with this one... except that it could be confused with UnsafeMutablePointer.initialize(repeating:), but I’ll ignore that since we already discussed it.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><span style="font-family:monospace,monospace" class="">assign(repeating:)</span></div><div class="gmail_extra"><span style="font-family:monospace,monospace" class="">deinitialize()</span></div></div></div></blockquote><div><br class=""></div><div>These are fine only if we have use cases that warrant them AND those use cases are expected to fully initialize the buffer, either via initialize(repeating:) or initialize(from: buffer) with precondition(source.count==self.count). They don’t really make sense for the use case that I’m familiar with. Without clear motivating code patterns, they aren’t worth the risk. “API Completeness” doesn’t have intrinsic value.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra">and the other methods should take both an <i class="">offset</i> 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 style="font-family:monospace,monospace" class="">allocate(capacity:)</span> and <span style="font-family:monospace,monospace" class="">deallocate()</span> into <span style="font-family:monospace,monospace" class="">UnsafeMutableBufferPointer</span>!)</div></div>
</div></blockquote><br class=""></div><div>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><br class=""></div><div>-Andy</div></body></html>