<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 29, 2017, at 1:23 PM, Taylor Swift <<a href="mailto:kelvin13ma@gmail.com" class="">kelvin13ma@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote class="gmail_quote" 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; 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="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><div class=""><div class="">I think this is a reasonable argument and convinced myself that it's possible to extend the slice API. I'm also convinced now that we don't need overloads to handle an UnsafeBufferPointer source, instead we can provide a single generic entry point on both UnsafeMutableBufferPointer and its slice, optimized within the implementation:</div><div class=""><br class=""></div><div class=""> `initialize<S : Sequence>(from: S) -> (S.Iterator, Index)</div><div class=""><br class=""></div><div class="">We can always drop down to the UnsafePointer API to get back to a direct unsafe implementation as a temporary workaround for performance issues.<span class="Apple-converted-space"> </span><br class=""></div></div></div></div></blockquote><div 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;" class=""><br class=""></div></div></blockquote><div><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Using <span class="" style="font-family: monospace, monospace;">Sequence</span>s throws out a whole host of assumptions we’ve been taking advantage of. We can’t check for <span class="" style="font-family: monospace, monospace;">source.count</span> anymore since that requires traversing the entire <span class="" style="font-family: monospace, monospace;">Sequence</span>.</div></div></div></div></blockquote><div><br class=""></div><div><span style="font-family: monospace, monospace;" class="">Sequence</span> provides <span style="font-family: monospace, monospace;" class="">underestimatedCount</span>. In the case of unsafe buffer types, <span style="font-family: monospace, monospace;" class="">underestimatedCount</span> just gives the <span style="font-family: monospace, monospace;" class="">count</span>. A requirement of <span style="font-family: monospace, monospace;" class="">initialize(from: source)</span> is that the caller must provide at least enough room for the <span style="font-family: monospace, monospace;" class="">underestimatedCount</span>.</div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">And if the performance is so bad relative to the <span class="" style="font-family: monospace, monospace;">UnsafePointer</span> API, we have to ask what the purpose of such a buffer API would even be. </div></div></div></div></blockquote><div><br class=""></div><div>It shouldn’t be much different, performance-wise. <span style="font-family: monospace, monospace;" class="">initialize(from:)</span> bounces directly into a call to <span style="font-family: monospace, monospace;" class="">source.</span><span style="font-family: monospace, monospace;" class="">_copyContents(initializing:)</span>, which can be specialized to perform lower-level memory copying operations (as it is already for types like array). The optimizer needs to ensure that this is just as efficient as if we had an <span style="font-family: monospace, monospace;" class="">initialize</span> that took an unsafe buffer. It ought to do this already, but if not, the implementation of this SE should include making sure it does. As a last resort, we could add concrete overloads for buffers – but bear in mind, you want at least to be able to initialize from 1) an UnsafeBufferPointer, 2) an UnsafeMutableBufferPointer, and 3) slices of 1 and 2. This would probably mean we need some kind of generic method regardless.</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">The whole purpose of the buffer API was to make it easier to do things with pointers without having to keep track of buffer lengths externally. It should be built around the <span class="" style="font-family: monospace, monospace;">UnsafePointer</span> API, not the much higher level <span class="" style="font-family: monospace, monospace;">Sequence</span> API.<br class=""></div><div class=""> </div></div></div></div></blockquote><div><br class=""></div><div>This would come at a cost of essentially duplicating API surface area for both concrete and generic <span style="font-family: monospace, monospace;" class="">source</span>. This should only be done for very good reasons, and performance issues that can be resolved as part of the implementation aren’t necessarily a sufficient one.</div><div class=""><br class=""></div></div></div></div></div><br class=""><blockquote type="cite" class=""><div class=""><blockquote class="gmail_quote" 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; 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="word-wrap: break-word; line-break: after-white-space;" class=""><div class=""><div class=""><div class=""></div><div class=""><br class=""></div><div class="">Let's set aside for now whether we support full or partial initialization/assignment, how to handle moveInitialize, and whether we need to return the Iterator/Index. This is going to require another iteration on swift-evolution, which<span class="Apple-converted-space"> </span><b class="">we should discuss in a separate thread</b>. </div><div class=""><br class=""></div><div class="">At this point, I suggest removing the controversial aspects of SE-0184 so that we can put the other changes behind us and focus future discussion around a smaller follow-up proposal.</div><div class=""><br class=""></div><div class="">Here I've summarized the changes that I think could be accepted as-is:</div><div class=""><a href="https://gist.github.com/atrick/c1ed7afb598e5cc943bdac7683914e3e" target="_blank" class="">https://gist.github.com/atrick<wbr class="">/c1ed7afb598e5cc943bdac7683914<wbr class="">e3e</a></div><div class=""><br class=""></div><div class="">If you amend SE-0184 accordingly and file a new PR, I think it can be quickly approved.</div><div class=""><br class=""></div><div class="">-Andy</div></div><div class=""><br class=""></div></div></div></blockquote><br class="Apple-interchange-newline"></div></blockquote></div><br class=""></body></html>