[swift-evolution] SE-0138 UnsafeRawBufferPointer

[Ben Rimmington]

> On 14 Sep 2016, at 17:08, Andrew Trick via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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.

An example without `Unsafe` in the function name:

<https://developer.apple.com/reference/swift/string/1538904-withcstring>

-- Ben