<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 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="">Using<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">Sequence</span>s throws out a whole host of assumptions we’ve been taking advantage of. We can’t check for<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">source.count</span>anymore since that requires traversing the entire<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">Sequence</span>. And if the performance is so bad relative to the<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">UnsafePointer</span><span class="Apple-converted-space"> </span>API, we have to ask what the purpose of such a buffer API would even be. 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="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">UnsafePointer</span><span class="Apple-converted-space"> </span>API, not the much higher level<span class="Apple-converted-space"> </span><span style="font-family: monospace, monospace;" class="">Sequence</span><span class="Apple-converted-space"> </span>API.</div></div></blockquote></div><br class=""><div class="">Those are good points. I’m also somewhat concerned about -Onone performance. Can you point to some code in your library that becomes excessively redundant by specifying the source.count at the call site?</div><div class=""><br class=""></div><div class="">-Andy</div></body></html>