<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 19, 2016, at 1:58 PM, Andrew Trick via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 18, 2016, at 12:28 AM, Quinn The Eskimo! via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">On 17 Aug 2016, at 18:55, Martin R via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">- Are both solutions correct, should one be preferred, or are both wrong?<br class=""></blockquote><br class="">Your `withMemoryRebound` solution is correct.<br class=""></div></div></blockquote><div class=""><br class=""></div>Absolutely, withMemoryRebound is always safe. You can use it whenever you just need to reinterpret memory at a call site and know the number of values stored that memory location. In this case it’s “easy" because you’re dealing a single sockaddr_in.</div><div class=""><br class=""></div><div class="">The UnsafeRawPointer proposal is the definitive reference</div><div class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md</a></div><div class=""><br class=""></div><div class="">But this migration guide is more approachable… it’s still WIP:</div><div class=""><a href="https://gist.github.com/atrick/0283ae0e284610fd21ad6ed3f454a585" class="">https://gist.github.com/atrick/0283ae0e284610fd21ad6ed3f454a585</a></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">- Can the same be achieved simpler?<br class=""></blockquote><br class="">Not without introducing a layer of abstraction.<br class=""><br class="">In my case I introduced an abstract `Address` type (basically a wrapper around `sockaddr_storage`) and then added a method to that object which calls a closure with the right parameters (actually, multiple such methods, depending on whether I’m calling something like `connect` which takes an address, or `getpeername`, which returns one). This approach concentrates all the ugly in one place, making the rest of my BSD Sockets code much cleaner.<br class=""></div></div></blockquote></div><br class=""><div class=""><div class="">This is an annoying UpdatePointer migration case because it falls under the category of misbehaving C APIs that we deliberately don't want to encourage in Swift.</div><div class=""><br class=""></div><div class="">The only good answer is to provide a Swift wrapper on top of the socket API as Quinn has done. It would be nice to post that code at some point so users of the socket API can copy-paste into their project.</div></div></div></div></blockquote><div><br class=""></div><div>I wonder if we could provide it via an overlay or if it is a more general thing that could use a generic/protocol? Just a random thought.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">-Andy</div></div>_______________________________________________<br class="">swift-users mailing list<br class=""><a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-users<br class=""></div></blockquote></div><br class=""></body></html>