[swift-evolution] SE-0138 UnsafeBytes

[Dave Abrahams]

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
  “typed,” memory.

- “Buffer,” because it works on a series of contiguous elements of known
  length.

- “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
this way.

>  * How much effort did you put into your review? A glance, a quick
>  reading, or an in-depth study?

Enough ;-)

-- 
-Dave, posting as a reviewer, not a review manager