I have to agree here that UnsafeBytes reads much better and makes more intuitive sense at call sites than any of the alternatives.<br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 12, 2016 at 23:34 Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Aug 12, 2016, at 9:13 PM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" target="_blank">felixcca@yahoo.ca</a>> wrote:</div><br><div><div style="word-wrap:break-word">Can we do a quick recap? Please correct me if I'm wrong.<div><br></div><div><ul><li>UnsafePointer: pointer to memory that the compiler may assume to be typed. Bounds unknown.</li><li>UnsafeBufferPointer: pointer to several objects that the compiler may assume to be typed Bounds known.</li><li>UnsafeRawPointer: pointer to memory that the compiler cannot assume to be typed. Bounds unknown.</li></ul><div><br></div><div>I think that I'm coming to the same conclusion as Brent, that UnsafeBytes is to UnsafeRawPointer what UnsafeBufferPointer is to UnsafePointer.</div><div><br></div><div>It seems to me that this could be neatly laid out in a matrix, and to me that kind of justifies giving similar names.</div><div><br></div><div><div><font face="Consolas"> One logical object Many logical objects</font></div><div><font face="Consolas">Typed UnsafePointer UnsafeBufferPointer</font></div><div><font face="Consolas">Untyped UnsafeRawPointer UnsafeBytes</font></div></div><div><br></div><div>One thing that I don't really like about UnsafeBytes is that it poorly conveys that the memory is not typed. In fact, it looks like it's typed to be UInt8. (From what I recall, C++'s strict aliasing does an exception for arrays of chars, but that's not a reason to import that notion in Swift.)</div><div>
<br><span style="font-family:'Lucida Grande';font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Félix</span>
</div></div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div>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 the memory access used to read or write those elements is untyped. It’s precisely for code that needs to stream bytes into or out of an object without thinking about binding memory to a type.</div><div><br></div><div>`bytes` is already our commonly used label for either untyped memory of UInt8 sized values, or for `UnsafeBufferPointer<UInt8>`. But these two things are frustratingly incompatible. `UnsafeBytes` is much more important than filling in that square in your matrix. It also does away with the now common, but incorrect use of `UnsafeBufferPointer<UInt8>` all over the place.</div><div><br></div><div>Look at the examples, imagine you’ve never heard of an UnsafeRawPointer, and see if you can come up with a better API. This all makes perfect sense when you approach the problem from the common use cases, rather than from a standard library implementer’s point of view.</div><div><br></div><div>-Andy</div></div><div style="word-wrap:break-word"><div><br></div><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div>
<div><blockquote type="cite"><div>Le 12 août 2016 à 19:47:36, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> a écrit :</div><br><div><div><br><blockquote type="cite">On Aug 12, 2016, at 7:32 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:<br><br><blockquote type="cite">On Aug 12, 2016, at 6:12 PM, Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br>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><br>Proposal:<br><br><a href="https://github.com/atrick/swift-evolution/blob/unsafebytes/proposals/NNNN-UnsafeBytes.md" target="_blank">https://github.com/atrick/swift-evolution/blob/unsafebytes/proposals/NNNN-UnsafeBytes.md</a><br><br><NNNN-UnsafeBytes.md><br></blockquote><br>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></blockquote><br>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.<br><br>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.<br><br>-Andy<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></blockquote></div><br></div></div></div></blockquote></div><br></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>