> On Aug 12, 2016, at 7:32 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Aug 12, 2016, at 6:12 PM, Andrew Trick via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> This proposal adds basic usability for working with raw memory without >> breaking source. The need to provide higher level API for working with raw >> memory buffers has always been evident, but making improvements in this area >> depended on first introducing `UnsafeRawPointer`. It was not clear until the >> final week of source-breaking changes whether SE-0107 would make it into >> Swift 3. Now that it has, we should use the little remaining time to improve >> the migration experience and encourage correct use of the memory model by >> introducing a low-risk additive API. >> >> Proposal: >> >> https://github.com/atrick/swift-evolution/blob/unsafebytes/proposals/NNNN-UnsafeBytes.md >> >> <NNNN-UnsafeBytes.md> > > I've only read a little but so far, but: Is the difference between this and > UnsafeBufferPointer that it's built around a raw pointer rather than a bound > pointer? If so, would UnsafeRawBufferPointer be a better name?
Yes that’s exactly right. Semantically, reads or writes on `UnsafeBytes` are untyped memory accesses. So you can get bytes into or out of it without binding memory. But as you’ll see from the interfaces and examples I’ve shown, `UnsafeMutableRawBufferPointer` would be a terrible name. There’s no reason from the user’s point of view to link this type to `UnsafeBufferPointer` and that names conveys no additionally useful information. It’s often viewed as just a collection of Bytes and potentially an important type for a number of public interfaces. -Andy _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
