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.<br><br>Question, though: In what sense is UnsafeBytes unsafe?<br><br><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 12, 2016 at 20:12 Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Hi swift-evolutionaries,</div><div><br></div><div>I'm sorry to bring a proposal late to the table, but this could make a big difference to the Swift 3 migration experience.</div><div><br></div><div>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.</div><div><br></div><div>Proposal:</div><div><br></div><div><a href="https://github.com/atrick/swift-evolution/blob/unsafebytes/proposals/NNNN-UnsafeBytes.md" target="_blank">https://github.com/atrick/swift-evolution/blob/unsafebytes/proposals/NNNN-UnsafeBytes.md</a></div><div><br></div><div></div></div><div style="word-wrap:break-word"><div></div><div><br></div><div>Intro:</div><div><br></div><div>[SE-0107: UnsafeRawPointer](<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md</a>) 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]().</div><div><br></div><div>-Andy</div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>