<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 Feb 1, 2017, at 15:17, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">On 2 Feb 2017, at 00:06, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">I agree with Chris on both counts. Either we need to continue to import ‘NSFoo <NSBar> *’ as ‘NSFoo’ in the Swift 4 compiler’s “Swift 3 compatibility mode”, or we need to come up with all the cases where a normally-unsound conversion needs to be permitted (possibly with a warning) in order to avoid breaking existing programs. The latter is technically doable, but would be much more work, which would likely hurt the proposal’s chances of getting into Swift 4.</div></div></blockquote><div class=""><br class=""></div><div class="">I don't know what you think, but I don't see much advantage in importing it as NSFoo & NSBar is Swift 3 compatibility mode. I wouldn't mind it being a Swift 4 mode only of the importer.</div><div class=""><br class=""></div><div class="">Correct?</div></div></div></blockquote><br class=""></div><div>That’s my thinking too. I’d (we’d) just like to see it called out more explicitly in the proposal. :-) You could list the other approach as “alternatives considered”, even if it was only briefly considered, or you could just leave it out.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>