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@swift.org> wrote: > > >> On Aug 13, 2016, at 7:12 AM, Félix Cloutier <felix...@yahoo.ca >> <mailto:felix...@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 <atr...@apple.com >>> <mailto:atr...@apple.com>> a écrit : >>> >>> >>>> On Aug 13, 2016, at 12:17 AM, Brent Royal-Gordon <br...@architechies.com >>>> <mailto:br...@architechies.com>> wrote: >>>> >>>>> On Aug 12, 2016, at 9:34 PM, Andrew Trick <atr...@apple.com >>>>> <mailto:atr...@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
