[swift-evolution] [late pitch] UnsafeBytes proposal

[Félix Cloutier]

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?

Félix

> Le 13 août 2016 à 01:44:28, Andrew Trick <atrick at apple.com> a écrit :
> 
> 
>> On Aug 13, 2016, at 12:17 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> 
>>> On Aug 12, 2016, at 9:34 PM, Andrew Trick <atrick at apple.com> wrote:
>>> 
>>> 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`. 
>> 
>> 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?
> 
> 
> 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?
> 
> 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.
> 
> -Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160813/8cc6176e/attachment.html>