> On Sep 10, 2016, at 5:53 PM, Andrew Trick <[email protected]> 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
>> <[email protected]> wrote:
>>
>>
>> on Thu Sep 01 2016, Andrew Trick <[email protected]> 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
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
