> On Dec 27, 2016, at 12:16 AM, Karl via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
