<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 13, 2016, at 7:12 AM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">And then, we can't really use UnsafeBufferPointer<UInt8> for the purpose of UnsafeBytes because we want to expose a different API. Is that right?<br class=""></div></div></blockquote><div><br class=""></div><div>UnsafeBufferPointer<UInt8> should be used in the same situation that UnsafePointer<T> is used for any T. A view over an array of UInt8 that can bypasses release bounds checks and can interoperate with C.</div><div><br class=""></div><div>UnsafeBufferPointer<UInt8> should not be used to erase the memory’s pointee type.</div><div><br class=""></div><div>UnsafeBytes erases the pointee type and gives algorithms a collection of bytes to work with. It turns out to be an important use case that I very much want to distinguish from the UnsafeBufferPointer use case. I don’t want to present users with a false analogy to UnsafeBufferPointer.</div><div><br class=""></div><div>-Andy</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 13 août 2016 à 01:44:28, Andrew Trick <<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Aug 13, 2016, at 12:17 AM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Aug 12, 2016, at 9:34 PM, Andrew Trick <<a href="mailto:atrick@apple.com" class="">atrick@apple.com</a>> wrote:<br class=""><br class="">That matrix is the correct starting point. UnsafeRawBufferPointer would be in the lower right. But it would be nothing more than a raw pointer with length. It wouldn’t be a collection of anything. UnsafeBytes is a powerful abstraction on top of what we just called UnsafeRawBufferPointer. It is a collection of typed elements `UInt8`. <br class=""></blockquote><br class="">But how is that different from UnsafeBufferPointer? Put another way, what is it about the UnsafeRawPointer -> UnsafeBytes relationship that isn't true about UnsafePointer -> UnsafeBufferPointer, and that therefore justifies the different name?<br class=""></blockquote><br class=""><br class="">Giving UnsafeRawPointer a memory size doesn’t imply a collection of any specific type. You’re supposed to used bindMemory(to:capacity:) to get a collection out of it. Giving UnsafeBytes a name analogous to UnsafeBufferPointer only exposes that subtle difference, which is actually irrelevant. In the common case, users don’t need to know how UnsafeRawPointer works, so why start with that analogy?<br class=""><br class="">The use cases justify the name. `UnsafeBytes` is what developers have been trying to get all along with `UnsafeBufferPointer<UInt8>`. The concept already exists to developers, but we have failed to give them a distinct, simple, and intuitive name for it, not to mention a correct implementation.<br class=""><br class="">-Andy</div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>