<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 Sep 11, 2016, at 3:07 AM, Ben Rimmington <<a href="mailto:me@benrimmington.com" class="">me@benrimmington.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On 11 Sep 2016, at 01:53, Andrew Trick wrote:<br class=""><br class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md</a><br class=""><br class="">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:<br class=""><br class="">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...<br class=""></blockquote><br class="">Does the `enumerateBytes` method (of Foundation.Data and DispatchData) also need an UnsafeRawBufferPointer version?<br class=""></div></div></blockquote></div><div class=""><br class=""></div>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:<div class=""><div class=""><a href="https://github.com/atrick/swift/commit/19968405608fa326eb7ad5ffed5fcd9a78b0f0a5" class="">https://github.com/atrick/swift/commit/19968405608fa326eb7ad5ffed5fcd9a78b0f0a5</a></div></div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">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.<br class=""><div class=""><br class=""></div><div class="">-Andy</div></div></body></html>