[swift-evolution] SE-0138 UnsafeBytes
dabrahams at apple.com
Fri Sep 2 13:14:56 CDT 2016
on Thu Sep 01 2016, Andrew Trick <swift-evolution at swift.org> wrote:
> I’m resending this for Review Manager Dave A. because the announce list is dropping his messages...
> Hello Swift community,
> The review of "UnsafeBytes" begins now and runs through September
> 7th. This late addition to Swift 3 is a follow-up to SE-0107:
> UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer,
> allowing developers to continue working with collections of UInt8 values,
> but now doing so via a type safe API. The UnsafeBytes API will not require
> direct manipulation of raw pointers or reasoning about binding memory.
> The proposal is available here:
> <https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md <https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md>>
> * What is your evaluation of the proposal?
I strongly support inclusion of the feature, but I have issues with the
name. It seems to me that in order to fit into the standard library, it
should be called Unsafe[Mutable]RawBufferPointer. Each part of the name
conveys something important, and for the same reasons we're using
Unsafe[Mutable]BufferPointer instead of UnsafeMutableElements, we should
stick to the scheme:
- “Unsafe,” because you can break memory safety with this tool
- “Raw,” because the fundamental model is that of “raw,” rather than
- “Buffer,” because it works on a series of contiguous elements of known
- “Pointer,” because it has reference semantics! When you pass one of
these things around by value, you're not passing the bytes; you're
passing a shared reference to the bytes.
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
Yes, and it fills an important funcationality gap now that we have the
unsafe pointer model nailed down.
> * Does this proposal fit well with the feel and direction of Swift?
Yes, except for the name.
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
I don't think any other language distinguishes raw from typed memory in
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
-Dave, posting as a reviewer, not a review manager
More information about the swift-evolution