> On Sep 11, 2016, at 2:29 PM, Rick Mann <rm...@latencyzero.com> wrote: > > 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.
Sure, enumerateBytes is fine for you. To be clear, it would only be a problem if Data did not own the memory (bytesNoCopy:), allowing the same memory to be accessed as a non-UInt8 type. -Andy > >> On Sep 10, 2016, at 19:33 , Andrew Trick <atr...@apple.com> wrote: >> >> >>> On Sep 10, 2016, at 6:23 PM, Rick Mann via swift-evolution >>> <swift-evolution@swift.org> 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 >>>> <swift-evolution@swift.org> 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 >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> >>>>> on Thu Sep 01 2016, Andrew Trick <swift-evolution@swift.org> 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 >>>>> 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 >>> >>> >>> -- >>> Rick Mann >>> rm...@latencyzero.com >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > > -- > Rick Mann > rm...@latencyzero.com > > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution