+1 as well. I would love to have Data.withUnsafeBytes use this type, and I agree that UnsafeBytes and Data have orthogonal and not overlapping use cases. On Sat, Sep 3, 2016 at 08:59 gs. via swift-evolution < swift-evolution@swift.org> wrote:
> +1 > > I think that 'Unsafe' is fine because the mutable variant is definitely > unsafe. > > I have some audio related code that would benefit greatly from this > addition so I am all for it. > > TJ > > > On Sep 1, 2016, at 12:10, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > Hello Swift community, > > > > The review of "UnsafeBytes" begins now and runs through September > > 7th. This late addition to Swift 3 is a follow-up to SE-0107: > > UnsafeRawPointer. It addresses common use cases for UnsafeRawPointer, > > allowing developers to continue working with collections of UInt8 values, > > but now doing so via a type safe API. The UnsafeBytes API will not > require > > direct manipulation of raw pointers or reasoning about binding memory. > > > > The proposal is available here: > > > > < > https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md > > > > > > Reviews are an important part of the Swift evolution process. All reviews > > should be sent to the swift-evolution mailing list at > > > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > or, if you would like to keep your feedback private, directly to the > > review manager. When replying, please try to keep the proposal link at > > the top of the message: > > > > Proposal link: > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > What goes into a review? > > > > The goal of the review process is to improve the proposal under review > > through constructive criticism and, eventually, determine the direction > of > > Swift. When writing your review, here are some questions you might want > to > > answer in your review: > > > > * What is your evaluation of the proposal? > > * Is the problem being addressed significant enough to warrant a > > change to Swift? > > * Does this proposal fit well with the feel and direction of Swift? > > * If you have used other languages or libraries with a similar > > feature, how do you feel that this proposal compares to those? > > * How much effort did you put into your review? A glance, a quick > > reading, or an in-depth study? > > > > More information about the Swift evolution process is available at > > > > <https://github.com/apple/swift-evolution/blob/master/process.md> > > > > Thank you, > > > > -Dave Abrahams > > Review Manager > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution