Thanks i'll try to clarify in the comments that The memory is read out as UInt8 but the memory is untyped.
Andy > On Aug 15, 2016, at 11:55 AM, Michael Ilseman <milse...@apple.com> wrote: > > 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> 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> a écrit : >>>>> >>>>> >>>>>> On Aug 13, 2016, at 12:17 AM, Brent Royal-Gordon >>>>>> <br...@architechies.com> wrote: >>>>>> >>>>>> On Aug 12, 2016, at 9:34 PM, Andrew Trick <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
