> 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
