<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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 Jul 6, 2016, at 7:51 AM, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" class="">charlie@charliemonroe.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">* <b class="">Remove unsafeAddressOf</b>. "We are not aware of any real use cases for it. If there are any, it should be renamed to unsafeAddress(of:) to follow the guidelines." (<a href="https://bugs.swift.org/browse/SR-1957" class="">https://bugs.swift.org/browse/SR-1957</a> <a href="rdar://problem/18589289" class="">rdar://problem/18589289</a>)</div></div></blockquote><div class=""><br class=""></div><div class="">I've mentioned on the bug report a few places in my code where I use the unsafeAddressOf - it can be used nicely to log the pointer to an instance - useful for debugging and is much shorter than </div><div class=""><br class=""></div><div class="">Unmanaged.passUnretained(x).toOpaque()</div><div class=""><br class=""></div><div class="">as Dmitri suggested - and clearer in a way - you are logging an address, you shouldn't have to deal with retain/unretained at all.</div><div class=""><br class=""></div><div class="">I'm definitely for keeping it around, the renaming seems good to me. Alternative to renaming it is to move this under Unmanaged:</div><div class=""><br class=""></div><div class="">Unmanaged.address(of: obj)</div><div class=""><br class=""></div><div class="">BTW Xcode 8 already sees it as renamed to unsafeAddress(of:).</div></div></div></div></blockquote><div><br class=""></div><div>Can you take lead on this batch of items? It sounds like you have an existing interest and expertise.</div><div><br class=""></div><div>-- E</div><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=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">* <b class="">Consider renaming or eliminating ManagedProtoBuffer</b>. "The reason why ManagedProtoBuffer exists is to give the users an extra bit of type safety inside of the closure passed to ManagedBuffer.create(). This closure receives the ManagedBuffer instance and returns the initial value that is stored in the buffer (the header part of the buffer). We are passing the ManagedBuffer as ManagedProtoBuffer to prevent the closure from reading the uninitialized value property. Maybe this extra bit of safety is not worth the API surface complexity." (<a href="https://bugs.swift.org/browse/SR-1955" class="">https://bugs.swift.org/browse/SR-1955</a> <a href="rdar://problem/26012924" class="">rdar://problem/26012924</a> <a href="rdar://problem/27118532" class="">rdar://problem/27118532</a>.")</div><div class=""><br class=""></div><div class="">* <b class="">withUnsafePointer shouldn't take its argument as inout</b>. (<a href="https://bugs.swift.org/browse/SR-1956" class="">https://bugs.swift.org/browse/SR-1956</a> <a href="rdar://problem/25019862" class="">rdar://problem/25019862</a>) Note: "Jordan has objections, see <a href="https://bugs.swift.org/browse/SR-1956" class="">https://bugs.swift.org/browse/SR-1956</a>"</div><div class=""><br class=""></div><div class="">-- E</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>