On Aug 12, 2016, at 9:13 PM, Félix Cloutier <firstname.lastname@example.org> 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.)
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
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.
Le 12 août 2016 à 19:47:36, Andrew Trick via swift-evolution < > email@example.com> a écrit :
On Aug 12, 2016, at 7:32 PM, Brent Royal-Gordon <firstname.lastname@example.org> > wrote:
On Aug 12, 2016, at 6:12 PM, Andrew Trick via swift-evolution < > email@example.com> 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.
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
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.
swift-evolution mailing list
swift-evolution mailing list