[swift-evolution] SE-0138 UnsafeRawBufferPointer

[Rien]

Now that “Raw” is introduced, also using “Unsafe” seems redundant to me. So ditch the unsafe and just go for “withRawBytes” and “withMutableRawBytes”.
I expect that most code that uses this type wil already have a name indicating that it concerns a byte buffer pointer, so “withRawBytes” should give sufficient clue as to what is going on.

Rien.

> On 11 Sep 2016, at 02: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