[swift-evolution] [late pitch] UnsafeBytes proposal
xiaodi.wu at gmail.com
Fri Aug 12 21:05:01 CDT 2016
Only very recently, I remember running into the very issue identified in
this write-up regarding the Data API. I'm glad that this proposal is aiming
to address some of that.
Question, though: In what sense is UnsafeBytes unsafe?
On Fri, Aug 12, 2016 at 20:12 Andrew Trick via swift-evolution <
swift-evolution at swift.org> wrote:
> Hi swift-evolutionaries,
> I'm sorry to bring a proposal late to the table, but this could make a big
> difference to the Swift 3 migration experience.
> This proposal adds basic usability for working with raw memory without
> breaking source. The need to provide higher level API for working with raw
> memory buffers has always been evident, but making improvements in this
> area depended on first introducing `UnsafeRawPointer`. It was not clear
> until the final week of source-breaking changes whether SE-0107 would make
> it into Swift 3. Now that it has, we should use the little remaining time
> to improve the migration experience and encourage correct use of the memory
> model by introducing a low-risk additive API.
> [SE-0107: UnsafeRawPointer](
> formalized Swift's memory model with respect to strict aliasing and
> prevented arbitrary conversion between `UnsafePointer` types. When moving
> to Swift 3, users will need to migrate much of their code dealing with
> `UnsafePointer`s. The new `UnsafeRawPointer` makes that possible. It
> provides a legal means to operate on raw memory (independent of the type of
> values in memory), and it provides an API for binding memory to a type for
> subsequent normal typed access. However, migrating to these new APIs is not
> always straightforward. It has become customary to use `[UInt8]` in APIs
> that deal with a buffer of bytes and are agnostic to the type of values
> held by the buffer. However, converting between `UInt8` and the client's
> element type at every API transition is difficult to do safely. See the
> [WIP UnsafeRawPointer Migration Guide]().
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution