> On Sep 11, 2016, at 3:07 AM, Ben Rimmington <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
