<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 12, 2016, at 7:05 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">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 class=""><br class="">Question, though: In what sense is UnsafeBytes unsafe?<br class=""></div></blockquote><div><br class=""></div><div>It’s not reference counted. UnsafeBytes is really a slice into raw memory that someone else is managing.</div><div><br class=""></div><div>It might be nice to have a reference counted wrapper for this, but that’s *much* lower priority and it’s not nearly as clear how that should be done.</div><div>All the use cases I’ve looked at so far want to use manual allocation/deallocation (for a simple temp buffer) or `Data` or [UInt8] to persist the memory.</div><div><br class=""></div><div>Note that [UInt8] can work well now as a temporary buffer as long as you’re using UnsafeBytes to copy data in:</div><div><br class=""></div><div><div>var buffer = [UInt8]()</div><div><br class=""></div><div>struct S {</div><div> var x: Int</div><div>}</div><div><br class=""></div><div>var s = S(x:3)</div><div><br class=""></div><div>withUnsafeBytes(of: &s) {</div><div> buffer += $0</div><div>}</div></div><div><br class=""></div><div>-Andy</div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Aug 12, 2016 at 20:12 Andrew Trick via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></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" class=""><div class="">Hi swift-evolutionaries,</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Proposal:</div><div class=""><br class=""></div><div class=""><a href="https://github.com/atrick/swift-evolution/blob/unsafebytes/proposals/NNNN-UnsafeBytes.md" target="_blank" class="">https://github.com/atrick/swift-evolution/blob/unsafebytes/proposals/NNNN-UnsafeBytes.md</a></div><div class=""><br class=""></div><div class=""></div></div><div style="word-wrap:break-word" class=""><div class=""></div><div class=""><br class=""></div><div class="">Intro:</div><div class=""><br class=""></div><div class="">[SE-0107: UnsafeRawPointer](<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md" target="_blank" class="">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 class=""><br class=""></div><div class="">-Andy</div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>