Thanks, Andrew. In my case, the Data reads from a file, and since the raw access is wrapped around the LZMA decompression, I think it should be safe (no one else is accessing the data at that time).
I'll just wait for Foundation.Data to be updated and update my code then. > On Sep 10, 2016, at 19:33 , Andrew Trick <[email protected]> wrote: > > >> On Sep 10, 2016, at 6:23 PM, Rick Mann via swift-evolution >> <[email protected]> wrote: >> >> Coincidentally, I just wrote my first Swift code to use UnsafePointer<>. I >> was wrapping the LZMA API to decompress LZMA data. It's a C API that works >> by pointing to an input buffer and and output buffer, and then calling a >> function that decompresses what it can given those two buffers (and their >> lengths). >> >> I treated them as UnsafePointer<UInt8>, but really they're raw, in the sense >> that they are not a collection of a single element, just a collection of >> bytes. >> >> My wrapper's interface to LZMA uses Data instances. I don't see a way of >> getting from Data to UnsafeRawBufferPointer in Xcode 8 GM seed (which makes >> sense, given that this is still in progress). But I also didn't see a way to >> get to UnsafeRawPointer; should there be? > > There should be and there isn't. It used to be Data.bytes, but it was just > deprecated. In the current state of limbo, you just do this: > > return data.withUnsafeBytes { bytes: UnsafeBufferPointer<UInt8> in … } > > and that binds Data’s memory to UInt8. It fine in practice as long as Data > owns its memory (not using bytesNoCopy). Otherwise whoever else uses the > memory should also view it as either raw or UInt8, or they should bind memory > each time they access it. > >> Will something be added to Data when SE-0138 is finalized? I guess that's >> not for Swift 3 but 3.x? > > Yes. It just takes a little more time to evolve the Data API. > > -Andy > >> Thanks, and sorry if I'm hijacking the thread a bit with this. >> >>> On Sep 10, 2016, at 17:53 , Andrew Trick via swift-evolution >>> <[email protected]> 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... >>> >>> In this code, it's obvious that a sequence of bytes is being appended to an >>> array. >>> >>> var buffer = [UInt8]() >>> withUnsafeBytes(of: &header) { >>> buffer += $0 >>> } >>> >>> In the following version, the closure argument type is obvious, which is >>> nice, but otherwise it's borderline unreadable, and doesn't describe what's >>> actually happenning. How can we tell that a sequence of bytes will be >>> appended? >>> >>> var buffer = [UInt8]() >>> withUnsafeRawBufferPointer(to: &header) { >>> buffer += $0 >>> } >>> >>> The mutable version really stretches the limits of descriptively naming >>> things, and still doesn't say anything about a byte sequence: >>> >>> withUnsafeMutableRawBufferPointer(to: &header) { >>> readHeader(into: $0) >>> } >>> >>> -Andy >>> >>>> On Sep 2, 2016, at 11:14 AM, Dave Abrahams via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> >>>> on Thu Sep 01 2016, Andrew Trick <[email protected]> wrote: >>>> >>>>> I’m resending this for Review Manager Dave A. because the announce list >>>>> is dropping his messages... >>>>> >>>>> 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 >>>>> >>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsafebytes.md>> >>>>> >>>>> * What is your evaluation of the proposal? >>>> >>>> I strongly support inclusion of the feature, but I have issues with the >>>> name. It seems to me that in order to fit into the standard library, it >>>> should be called Unsafe[Mutable]RawBufferPointer. Each part of the name >>>> conveys something important, and for the same reasons we're using >>>> Unsafe[Mutable]BufferPointer instead of UnsafeMutableElements, we should >>>> stick to the scheme: >>>> >>>> - “Unsafe,” because you can break memory safety with this tool >>>> >>>> - “Raw,” because the fundamental model is that of “raw,” rather than >>>> “typed,” memory. >>>> >>>> - “Buffer,” because it works on a series of contiguous elements of known >>>> length. >>>> >>>> - “Pointer,” because it has reference semantics! When you pass one of >>>> these things around by value, you're not passing the bytes; you're >>>> passing a shared reference to the bytes. >>>> >>>>> * Is the problem being addressed significant enough to warrant a >>>>> change to Swift? >>>> >>>> Yes, and it fills an important funcationality gap now that we have the >>>> unsafe pointer model nailed down. >>>> >>>>> >>>>> * Does this proposal fit well with the feel and direction of Swift? >>>> >>>> Yes, except for the name. >>>> >>>>> >>>>> * If you have used other languages or libraries with a similar >>>>> feature, how do you feel that this proposal compares to those? >>>> >>>> I don't think any other language distinguishes raw from typed memory in >>>> this way. >>>> >>>>> * How much effort did you put into your review? A glance, a quick >>>>> reading, or an in-depth study? >>>> >>>> Enough ;-) >>>> >>>> -- >>>> -Dave, posting as a reviewer, not a review manager >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> -- >> Rick Mann >> [email protected] >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > -- Rick Mann [email protected] _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
