[swift-evolution] [late pitch] UnsafeBytes proposal

Michael Ilseman milseman at apple.com
Mon Aug 15 13:55:11 CDT 2016


It seems like there’s a potential for confusion here, in that people may see “UInt8” and assume there is some kind of typed-ness, even though the whole point is that this is untyped. Adjusting the header comments slightly might help:


/// A non-owning view of raw memory as a collection of bytes.
///
/// Reads and writes on memory via `UnsafeBytes` are untyped operations that
/// do no require binding the memory to a type. These operations are expressed 
/// in terms of `UInt8`, though the underlying memory is untyped.

…

You could go even further towards hinting this fact with a `typealias Byte = UInt8`, and use Byte throughout. But, I don’t know if that’s getting too excessive.


> On Aug 13, 2016, at 9:34 AM, Andrew Trick via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Aug 13, 2016, at 7:12 AM, Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> wrote:
>> 
>> 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?
> 
> 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.
> 
> UnsafeBufferPointer<UInt8> should not be used to erase the memory’s pointee type.
> 
> 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.
> 
> -Andy
> 
>> 
>>> Le 13 août 2016 à 01:44:28, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> a écrit :
>>> 
>>> 
>>>> On Aug 13, 2016, at 12:17 AM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>>>> 
>>>>> On Aug 12, 2016, at 9:34 PM, Andrew Trick <atrick at apple.com <mailto: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
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160815/63f9b94f/attachment.html>


More information about the swift-evolution mailing list