<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 12, 2016, at 7:47 PM, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Aug 12, 2016, at 7:32 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Aug 12, 2016, at 6:12 PM, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">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.<br class=""><br class="">Proposal:<br class=""><br class=""><a href="https://github.com/atrick/swift-evolution/blob/unsafebytes/proposals/NNNN-UnsafeBytes.md" class="">https://github.com/atrick/swift-evolution/blob/unsafebytes/proposals/NNNN-UnsafeBytes.md</a><br class=""><br class=""><NNNN-UnsafeBytes.md><br class=""></blockquote><br class="">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?<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><div class=""><br class=""></div><div class=""><div class="">I can give you a less dissmissive answer to this, because there is potential for confusion given that the value is actually a view over the bytes, not the bytes. I just don't think a longer name will clarify the semantics:</div><div class=""><br class=""></div><div class="">- `Bytes` sufficiently conveys a region of raw memory.</div><div class=""><br class=""></div><div class="">- The `Unsafe` already hints that this is only a "view" into memory,</div><div class=""> not a copy of the Bytes, and suggests that the developer needs to</div><div class=""> consult the doc comment if using it in a non-idiomatic way.</div><div class=""><br class=""></div><div class="">- In the expected idioms (see examples) this simple name will be far</div><div class=""> more meaningful and less distracting.</div><div class=""><br class=""></div><div class="">- Adding `Raw` to the name is purely redundant and adding `Buffer`,</div><div class=""> and `Pointer` into the name would cause confusion.</div><div class=""><br class=""></div><div class="">I think both your and Xiaodi's comments can be addressed by clarifying</div><div class="">the doc comments:</div><div class=""><br class=""></div><div class="">/// A non-owning view of raw memory as a collection of `UInt8` bytes.</div><div class="">///</div><div class="">/// Reads and writes on memory via `UnsafeBytes` are untyped operations that</div><div class="">/// do no require binding the memory to `UInt8`.</div><div class="">///</div><div class="">/// In addition to the `Collection` interface, this provides a bounds-checked</div><div class="">/// version of `UnsafeMutableRawPointer`'s interface to raw memory:</div><div class="">/// `load(fromByteOffset:as:)`, `storeBytes(of:toByteOffset:as:)`, and</div><div class="">/// `copyBytes(from:count:)`.</div><div class="">///</div><div class="">/// Because this is only a view into memory, and does not own the memory,</div><div class="">/// copying a value of type `UnsafeMutableBytes` does not copy the underlying</div><div class="">/// memory. However, assigning into `UnsafeMutableBytes` via a subscript copies</div><div class="">/// bytes into the memory, and assigning an `UnsafeMutableBytes` into a</div><div class="">/// value-based collection, such as `[UInt8]` copies bytes out of memory.</div><div class="">///</div><div class="">/// Example:</div><div class="">///</div><div class="">/// // View a slice of memory at someBytes.</div><div class="">/// var destBytes = someBytes[0..<n]</div><div class="">///</div><div class="">/// // Copy `n` bytes of data from sourceBytes into that view.</div><div class="">/// destBytes[0..<n] = sourceBytes</div><div class="">///</div><div class="">/// // View a different slice memory at someBytes.</div><div class="">/// destBytes = someBytes[n..<m]</div></div><div class=""><br class=""></div><div class="">-Andy</div></body></html>