[swift-evolution] SE-0138 UnsafeRawBufferPointer

[Andrew Trick]

> On Sep 10, 2016, at 5:53 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md
> 
> The review period has been extended until September 14. The UnsafeRawBufferPointer type name is settled, but we still need to come up with an answer for the name of the new closure taking functions:
> 
> withXyz() should normally reveal the closure argument type as Xyz. That's why I originally proposed UnsafeBytes as the type name. Now that we've decided to use the descriptive type instead we have a problem…

I was totally wrong about this policy. In closure-taking “withXyz" functions, “Xyz" should reveal the role of the closure argument, not its type. We do not need to repeat type information.

We have strong agreement to leave the proposed `withUnsafeBytes {…}` name as it stands.

Note that `withRawBytes` was a strong contender, but at this time it's more important to consistently follow the convention for using `Unsafe` in the closure name whenever the closure argument is unsafe (e.g. you can't return it from the closure). We may want to revisit this logic later (in some sense Unsafe is redundant), but when we do that, we also need to reevaluate all of our withUnsafe APIs. Furthermore, we would want to change Foundation Data's API to be consistent. These are bigger debates that can be deferred.

-Andy

> 
> In this code, it's obvious that a sequence of bytes is being appended to an array.
> 
> var buffer = [UInt8]()
> withUnsafeBytes(of: &header) {
>  buffer += $0
> }
> 
> In the following version, the closure argument type is obvious, which is nice, but otherwise it's borderline unreadable, and doesn't describe what's actually happenning. How can we tell that a sequence of bytes will be appended?
> 
> var buffer = [UInt8]()
> withUnsafeRawBufferPointer(to: &header) {
>  buffer += $0
> }
> 
> The mutable version really stretches the limits of descriptively naming things, and still doesn't say anything about a byte sequence:
> 
> withUnsafeMutableRawBufferPointer(to: &header) {
>  readHeader(into: $0)
> }
> 
> -Andy
> 
>> On Sep 2, 2016, at 11:14 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 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
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>