[swift-evolution] SE-0138 UnsafeRawBufferPointer

Andrew Trick atrick at apple.com
Sun Sep 11 14:08:20 CDT 2016


> On Sep 11, 2016, at 3:07 AM, Ben Rimmington <me at benrimmington.com> wrote:
> 
> 
>> On 11 Sep 2016, at 01:53, Andrew Trick 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...
> 
> Does the `enumerateBytes` method (of Foundation.Data and DispatchData) also need an UnsafeRawBufferPointer version?


I think it should only have an UnsafeRawBufferPointer version. If the user wants to bind memory, they should do that explicitly. I’ve made the likely changes to Data on a branch:
https://github.com/atrick/swift/commit/19968405608fa326eb7ad5ffed5fcd9a78b0f0a5 <https://github.com/atrick/swift/commit/19968405608fa326eb7ad5ffed5fcd9a78b0f0a5>

There are enough changes to Data that I think it deserves a separate proposal and discussion thread. It’s useful to look ahead at how the Data API should look but I’m trying to get language-level changes accepted first (in some sense, Unsafe constructs are part of the language even if they don’t require compiler changes).

Also keep in mind, adding UnsafeRawBufferPointer does not make Data any less usable today. We just need to get core support in place so we can have a discussion about Foundation.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160911/779e8739/attachment.html>


More information about the swift-evolution mailing list