Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> 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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> 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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> 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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> 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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> 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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> 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

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

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: