Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Jeremy Pereira via swift-evolution]

> 
> Annotating that a parameter of a closure should not escape the closure is 
> probably a worthwhile thing to have, anyway. Currently we only allow that for 
> function-type parameters, but there are other parameters you might give (such 
> as the pointer in `String.withCString()`’s closure) which should not escape 
> their context.


It certainly needs to be at least explicitly documented somewhere. I’ve seen 
people use it in published code to obtain a pointer to (fro example) the bytes 
in an array without realising that the storage could easily go away.


> ___
> 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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Karl via swift-evolution]

> On 14 Sep 2016, at 18:08, Andrew Trick via swift-evolution 
>  wrote:
> 
> 
>> On Sep 10, 2016, at 5:53 PM, Andrew Trick  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…
> 
> I was totally wrong about this policy. In closure-taking “withXyz" functions, 
> “Xyz" should reveal the role of the closure argument, not its type. We do not 
> need to repeat type information.
> 
> We have strong agreement to leave the proposed `withUnsafeBytes {…}` name as 
> it stands.
> 
> Note that `withRawBytes` was a strong contender, but at this time it's more 
> important to consistently follow the convention for using `Unsafe` in the 
> closure name whenever the closure argument is unsafe (e.g. you can't return 
> it from the closure). We may want to revisit this logic later (in some sense 
> Unsafe is redundant), but when we do that, we also need to reevaluate all of 
> our withUnsafe APIs. Furthermore, we would want to change Foundation Data's 
> API to be consistent. These are bigger debates that can be deferred.

Annotating that a parameter of a closure should not escape the closure is 
probably a worthwhile thing to have, anyway. Currently we only allow that for 
function-type parameters, but there are other parameters you might give (such 
as the pointer in `String.withCString()`’s closure) which should not escape 
their context.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Ben Rimmington via swift-evolution]

> On 14 Sep 2016, at 17:08, Andrew Trick via swift-evolution 
>  wrote:
> 
>> On Sep 10, 2016, at 5:53 PM, Andrew Trick  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…
> 
> I was totally wrong about this policy. In closure-taking “withXyz" functions, 
> “Xyz" should reveal the role of the closure argument, not its type. We do not 
> need to repeat type information.
> 
> We have strong agreement to leave the proposed `withUnsafeBytes {…}` name as 
> it stands.
> 
> Note that `withRawBytes` was a strong contender, but at this time it's more 
> important to consistently follow the convention for using `Unsafe` in the 
> closure name whenever the closure argument is unsafe (e.g. you can't return 
> it from the closure). We may want to revisit this logic later (in some sense 
> Unsafe is redundant), but when we do that, we also need to reevaluate all of 
> our withUnsafe APIs. Furthermore, we would want to change Foundation Data's 
> API to be consistent. These are bigger debates that can be deferred.

An example without `Unsafe` in the function name:



-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Andrew Trick via swift-evolution]

> On Sep 10, 2016, at 5:53 PM, Andrew Trick  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…

I was totally wrong about this policy. In closure-taking “withXyz" functions, 
“Xyz" should reveal the role of the closure argument, not its type. We do not 
need to repeat type information.

We have strong agreement to leave the proposed `withUnsafeBytes {…}` name as it 
stands.

Note that `withRawBytes` was a strong contender, but at this time it's more 
important to consistently follow the convention for using `Unsafe` in the 
closure name whenever the closure argument is unsafe (e.g. you can't return it 
from the closure). We may want to revisit this logic later (in some sense 
Unsafe is redundant), but when we do that, we also need to reevaluate all of 
our withUnsafe APIs. Furthermore, we would want to change Foundation Data's API 
to be consistent. These are bigger debates that can be deferred.

-Andy

> 
> 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 
>>  wrote:
>> 
>> 
>> on Thu Sep 01 2016, Andrew Trick  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:
>>> 
>>> >>  
>>> >
>>> 
>>> * 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 

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Andrew Trick via swift-evolution]

> On Sep 11, 2016, at 2:29 PM, Rick Mann  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  wrote:
>> 
>> 
>>> On Sep 10, 2016, at 6:23 PM, Rick Mann via swift-evolution 
>>>  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, 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 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 
  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 
>  wrote:
> 
> 
> on Thu Sep 01 2016, Andrew Trick  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:
>> 
>> >  
>> >
>> 
>> * 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]RawBufferPoi

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Rick Mann via swift-evolution]

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  wrote:
> 
> 
>> On Sep 10, 2016, at 6:23 PM, Rick Mann via swift-evolution 
>>  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, 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 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 
>>>  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 
  wrote:
 
 
 on Thu Sep 01 2016, Andrew Trick  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:
> 
>   
> >
> 
> * 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,

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Andrew Trick via swift-evolution]

> On Sep 11, 2016, at 3:07 AM, Ben Rimmington  wrote:
> 
> 
>> On 11 Sep 2016, at 01:53, Andrew Trick 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...
> 
> Does the `enumerateBytes` method (of Foundation.Data and DispatchData) also 
> need an UnsafeRawBufferPointer version?


I think it should only have an UnsafeRawBufferPointer version. If the user 
wants to bind memory, they should do that explicitly. I’ve made the likely 
changes to Data on a branch:
https://github.com/atrick/swift/commit/19968405608fa326eb7ad5ffed5fcd9a78b0f0a5 


There are enough changes to Data that I think it deserves a separate proposal 
and discussion thread. It’s useful to look ahead at how the Data API should 
look but I’m trying to get language-level changes accepted first (in some 
sense, Unsafe constructs are part of the language even if they don’t require 
compiler changes).

Also keep in mind, adding UnsafeRawBufferPointer does not make Data any less 
usable today. We just need to get core support in place so we can have a 
discussion about Foundation.

-Andy___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Ben Rimmington via swift-evolution]

> On 11 Sep 2016, at 01:53, Andrew Trick 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...

Does the `enumerateBytes` method (of Foundation.Data and DispatchData) also 
need an UnsafeRawBufferPointer version?

-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Rien via swift-evolution]

Now that “Raw” is introduced, also using “Unsafe” seems redundant to me. So 
ditch the unsafe and just go for “withRawBytes” and “withMutableRawBytes”.
I expect that most code that uses this type wil already have a name indicating 
that it concerns a byte buffer pointer, so “withRawBytes” should give 
sufficient clue as to what is going on.

Rien.

> On 11 Sep 2016, at 02:53, Andrew Trick via swift-evolution 
>  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 
>>  wrote:
>> 
>> 
>> on Thu Sep 01 2016, Andrew Trick  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:
>>> 
>>> >>  
>>> >
>>> 
>>> * 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Andrew Trick via swift-evolution]

> On Sep 10, 2016, at 6:23 PM, Rick Mann via swift-evolution 
>  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, 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 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 
>>  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 
>>>  wrote:
>>> 
>>> 
>>> on Thu Sep 01 2016, Andrew Trick  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:
 
 >
 
 * 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 h

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Rick Mann via swift-evolution]

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, 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?

Will something be added to Data when SE-0138 is finalized? I guess that's not 
for Swift 3 but 3.x? 

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 
>  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 
>>  wrote:
>> 
>> 
>> on Thu Sep 01 2016, Andrew Trick  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:
>>> 
>>> >>  
>>> >
>>> 
>>> * 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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

[Andrew Trick via swift-evolution]

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 
>  wrote:
> 
> 
> on Thu Sep 01 2016, Andrew Trick  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:
>> 
>> >  
>> >
>> 
>> * 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