[swift-evolution] [late pitch] UnsafeBytes proposal

[Xiaodi Wu]

I have to agree here that UnsafeBytes reads much better and makes more
intuitive sense at call sites than any of the alternatives.
On Fri, Aug 12, 2016 at 23:34 Andrew Trick via swift-evolution <
swift-evolution at swift.org> wrote:

> On Aug 12, 2016, at 9:13 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
>
> Can we do a quick recap? Please correct me if I'm wrong.
>
>
>    - UnsafePointer: pointer to memory that the compiler may assume to be
>    typed. Bounds unknown.
>    - UnsafeBufferPointer: pointer to several objects that the compiler
>    may assume to be typed Bounds known.
>    - UnsafeRawPointer: pointer to memory that the compiler cannot assume
>    to be typed. Bounds unknown.
>
>
> I think that I'm coming to the same conclusion as Brent, that UnsafeBytes
> is to UnsafeRawPointer what UnsafeBufferPointer is to UnsafePointer.
>
> It seems to me that this could be neatly laid out in a matrix, and to me
> that kind of justifies giving similar names.
>
>             One logical object    Many logical objects
> Typed       UnsafePointer         UnsafeBufferPointer
> Untyped     UnsafeRawPointer      UnsafeBytes
>
> 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.)
>
> Félix
>
>
> 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.
>
> `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.
>
> 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.
>
> -Andy
>
> Le 12 août 2016 à 19:47:36, Andrew Trick via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
>
> On Aug 12, 2016, at 7:32 PM, Brent Royal-Gordon <brent at architechies.com>
> wrote:
>
> On Aug 12, 2016, at 6:12 PM, Andrew Trick via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160813/d25f7e3c/attachment.html>