<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 Mar 24, 2016, at 11:57 AM, Russ Bishop via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@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 Mar 24, 2016, at 10:26 AM, Alex Martini via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="section" id="allow-swift-types-to-provide-custom-objective-c-representations" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"><h3 style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px;" class="">Allow Swift types to provide custom Objective-C representations<a class="headerlink" href="file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/2016-03-23.html#allow-swift-types-to-provide-custom-objective-c-representations" title="Permalink to this headline" style="visibility: hidden; font-weight: bold; text-decoration: none; color: rgb(167, 206, 56); padding-left: 5px;"></a></h3><p style="text-align: justify;" class=""><a class="external reference" href="https://github.com/apple/swift-evolution/pull/198" style="font-weight: bold; text-decoration: none; color: rgb(137, 38, 1);">https://github.com/apple/swift-evolution/pull/198</a></p><p style="text-align: justify;" class="">The associated type could be <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">AnyObject</span></tt> rather than <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">NSObject</span></tt>. The use case for a non-subclass of <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">NSObject</span></tt> is very narrow, but it’s not a needed restriction.</p><p style="text-align: justify;" class="">The <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">unconditionalyBridgeFromObjectiveC</span></tt> function can probably go away. Calling initializers from the downcasting infrastructure is horrible. If we need a function, they</p></div></div></div></blockquote><div class="">Was there more to this line of thought? It looks like it got cut off.</div><div class=""><br class=""></div><div class="">I would like to unify this to either have the initializers or have the static functions but not both, but I don’t know which is preferred from an implementation perspective. The initializers feel more “Swifty” but moving back to static functions is perfectly workable.</div></div></div></div></blockquote><div><br class=""></div>The preference was to just have the initializers, since that is the preferred way to express conversions.</div><div><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=""><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="section" id="allow-swift-types-to-provide-custom-objective-c-representations" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"><p style="text-align: justify;" class="">Implicit conversions. In this proposals, you don’t get implicit conversions. Have a separate discussion about whether we can get rid of the four types that have implicit conversion. We see the existing ones as deeply problematic.</p></div></div></div></blockquote><div class="">The casting was a late addition to allow the user to work around situations where the ObjC API is deficient and to keep the behavior consistent with how other types are bridged. It could be removed if desired but I agree that it should probably be removed from the existing types as well in that case.</div><div class=""><br class=""></div><div class="">Removing it would unify behavior: conversion happens through initializers, casting through as. That means the example would be more like “let x = SwiftType(SomeObjCType)”. Strings become “let x = String(anNSString)”</div></div></div></blockquote><br class=""></div><div>Many of us would prefer to reduce the implicit conversions we have today in various ways (e.g. I’m a fan of disabling T -> T? promotion in operator argument contexts, which would solve a number of weird ?? issues). The existing implicit bridging conversions fall into the same category: it isn’t clear if we can eliminate them, but if we could, that would be great for predictability and for type checker performance.</div><div><br class=""></div><div>Upshot of this is that there doesn’t seem to be a reason for this new feature to add new implicit conversions: doing an explicit conversion with “as” seems fine.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>