[swift-evolution] SE-0138 UnsafeRawBufferPointer

[Karl]

> On 14 Sep 2016, at 18: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.

Annotating that a parameter of a closure should not escape the closure is probably a worthwhile thing to have, anyway. Currently we only allow that for function-type parameters, but there are other parameters you might give (such as the pointer in `String.withCString()`’s closure) which should not escape their context.