<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=""><blockquote type="cite" class="">On Mar 1, 2017, at 10:11 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><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=""><p style="color: rgb(17, 17, 17); font-family: 'Helvetica Neue', Helvetica, Arial, Verdana, sans-serif; word-wrap: break-word; margin: 1.3125em 0px; font-size: 1.1429em; line-height: 1.3125em;" class="">I’d like to investigate separating Objective-C bridging from the behavior of the <code style="line-height: 1;" class="">as</code>/<code style="line-height: 1;" class="">as?</code>/<code style="line-height: 1;" class="">is</code> operator family again for Swift 4. Last year, I proposed <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0083-remove-bridging-from-dynamic-casts.md" style="color: rgb(13, 110, 161); text-decoration: none; transition: color 0.2s ease-in-out; -webkit-transition: color 0.2s ease-in-out;" class="">SE–0083</a>, but we deferred the proposal for lack of time to evaluate its impact. As complicating factors, we now have source compatibility with Swift 3 as a requirement, and the <code style="line-height: 1;" class="">id</code>-as-<code style="line-height: 1;" class="">Any</code> work from <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md" style="color: rgb(13, 110, 161); text-decoration: none; transition: color 0.2s ease-in-out; -webkit-transition: color 0.2s ease-in-out;" class="">SE–0116</a> more or less requires bridging dynamic casts to work. </p></div></div></blockquote></div><div>That decision still seems strange to me. For a change that necessarily involves source breakage, let’s defer until after we’ve pledged source compatibility. Huh?</div><div><br class=""></div><div>Nevertheless, I’d be willing to put up with some source breakage for this, myself. The weird bridging behavior on “as” and friends is a good candidate for the single most confusing thing about Swift as it stands today.</div><div><br class=""></div><div>Charles</div><div><br class=""></div></body></html>