[swift-evolution] SE-0138 UnsafeRawBufferPointer

[Andrew Trick]

> On Sep 10, 2016, at 6:23 PM, Rick Mann via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Coincidentally, I just wrote my first Swift code to use UnsafePointer<>. I was wrapping the LZMA API to decompress LZMA data. It's a C API that works by pointing to an input buffer and and output buffer, and then calling a function that decompresses what it can given those two buffers (and their lengths).
> 
> I treated them as UnsafePointer<UInt8>, but really they're raw, in the sense that they are not a collection of a single element, just a collection of bytes.
> 
> My wrapper's interface to LZMA uses Data instances. I don't see a way of getting from Data to UnsafeRawBufferPointer in Xcode 8 GM seed (which makes sense, given that this is still in progress). But I also didn't see a way to get to UnsafeRawPointer; should there be?

There should be and there isn't. It used to be Data.bytes, but it was just deprecated. In the current state of limbo, you just do this:

  return data.withUnsafeBytes { bytes: UnsafeBufferPointer<UInt8> in … }

and that binds Data’s memory to UInt8. It fine in practice as long as Data owns its memory (not using bytesNoCopy). Otherwise whoever else uses the memory should also view it as either raw or UInt8, or they should bind memory each time they access it.

> Will something be added to Data when SE-0138 is finalized? I guess that's not for Swift 3 but 3.x? 

Yes. It just takes a little more time to evolve the Data API.

-Andy

> Thanks, and sorry if I'm hijacking the thread a bit with this.
> 
>> On Sep 10, 2016, at 17:53 , Andrew Trick via swift-evolution <swift-evolution at swift.org> 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...
>> 
>> 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
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> -- 
> Rick Mann
> rmann at latencyzero.com
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution