[swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

[Tony Parker]

Hi Andy, everyone,

The short answer is that fixing struct Data requires a source breaking change (the enum for the deallocator has to change to use the raw buffer type), so I do not want to introduce it until Swift 4 provides a better transition path for this kind of change.

- Tony

> On Jan 4, 2017, at 2:12 PM, Andrew Trick <atrick at apple.com> wrote:
> 
> 
>> On Dec 27, 2016, at 12:16 AM, Karl via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Looking for feedback before submitting a PR: https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/xxxx-corelibs-unsafebytes.md <https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/xxxx-corelibs-unsafebytes.md>
>> 
>> —
>> 
>> Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer
>> 
>> Proposal: SE-NNNN <https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/NNNN-filename.md>
>> Authors: Karl Wagner <https://github.com/karwa>
>> Review Manager: TBD
>> Status: Awaiting review
>> During the review process, add the following fields as needed:
>> 
>> Decision Notes: Rationale <https://lists.swift.org/pipermail/swift-evolution/>, Additional Commentary <https://lists.swift.org/pipermail/swift-evolution/>
>> Bugs: SR-NNNN <https://bugs.swift.org/browse/SR-NNNN>, SR-MMMM <https://bugs.swift.org/browse/SR-MMMM>
>> Previous Revision: 1 <https://github.com/apple/swift-evolution/blob/...commit-ID.../proposals/NNNN-filename.md>
>> Previous Proposal: SE-XXXX <https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/XXXX-filename.md>
>>  <https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/xxxx-corelibs-unsafebytes.md#introduction>Introduction
>> 
>> The standard library's Array and ContiguousArray types expose the method withUnsafeBytes, which allows you to view their contents as a contiguous collection of bytes. The core libraries Foundation and Dispatch contain types which wrap some allocated data, but their withUnsafeBytes method only allows you to view the contents as a pointer to a contiguous memory location of a given type.
>> 
>> Swift-evolution thread: Discussion thread topic for that proposal <https://lists.swift.org/pipermail/swift-evolution/>
>>  <https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/xxxx-corelibs-unsafebytes.md#motivation>Motivation
>> 
>> The current situation makes it awkward to write generic code. Personally, I use the following extension in my projects to sort the naming confusion out:
>> 
>> protocol ContiguousByteCollection {
>>   func withUnsafeBytes<T>(_ body: (UnsafeRawBufferPointer) throws -> T) rethrows -> T
>> }
>> 
>> // stdlib types are fine.
>> extension Array: ContiguousByteCollection {}
>> extension ArraySlice: ContiguousByteCollection {}
>> extension ContiguousArray: ContiguousByteCollection {}
>> 
>> // corelibs types give us a pointer<T>, should be: { pointer<char>, count }
>> #if canImport(Dispatch)
>>   import Dispatch
>> 
>>   extension DispatchData : ContiguousByteCollection {
>>     func withUnsafeBytes<T>(_ body: (UnsafeRawBufferPointer) throws -> T) rethrows -> T {
>>       return try withUnsafeBytes { try body(UnsafeRawBufferPointer(start: $0, count: count)) }
>>     }
>>   }
>> #endif
>> 
>> #if canImport(Foundation)
>>   import Foundation
>> 
>>   extension Data : ContiguousByteCollection {
>>     func withUnsafeBytes<T>(_ body: (UnsafeRawBufferPointer) throws -> T) rethrows -> T {
>>       return try withUnsafeBytes { try body(UnsafeRawBufferPointer(start: $0, count: count)) }
>>     }
>>   }
>> #endif
>> Conceptually, the corelibs types are untyped regions of memory, and it would make sense for them to adopt the UnsafeRawBufferPointer model.
>> 
>>  <https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/xxxx-corelibs-unsafebytes.md#proposed-solution>Proposed solution
>> 
>> The proposed solution would be to deprecate the current methods on (Dispatch)Data (with 2 generic parameters), and replace them with methods with identical signatures to Array (with 1 generic parameter).
>> 
>> To be deprecated:
>> 
>> public func withUnsafeBytes<ResultType, ContentType>(_ body: (UnsafePointer<ContentType>) throws -> ResultType) rethrows -> ResultType
>> Replaced with:
>> 
>> public func withUnsafeBytes<R>(_ body: (UnsafeRawBufferPointer) throws -> R) rethrows -> R
>>  <https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/xxxx-corelibs-unsafebytes.md#source-compatibility>
> Thanks Karl. Good observation.
> 
> I proposed exactly this API along with a few other UnsafeRawBufferPointer compatibility API’s during SE-0183. Look for Tony to follow up on this.
> 
> -Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170104/ea50eb3d/attachment.html>