<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=""><div><blockquote type="cite" class=""><div class="">On Jul 8, 2016, at 8:41 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><div 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="">On Jul 6, 2016, at 09:16, John McCall 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=""><div class=""><blockquote type="cite" class="">On Jul 5, 2016, at 10:56 PM, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:<br class=""><blockquote type="cite" class="">On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><br class="">I think Kevin Lundberg is right to worry about testability, but I don't think that has to prevent this change. Instead, we should permit `@testable` imports to subclass/override things that are not publicly subclassable/overridable, and thus a module built with "Enable Testability" on can't actually assume there are no subclasses/overrides of `internal` classes/members even if it doesn't see any. This will block optimizations in debug builds, but not in release builds. The proposal should be edited to explain this `@testable` behavior.<br class=""></blockquote><br class="">IIUC the basic design of @testable is to treat the tests for the testable thing as existing within its module, so I think this just falls out. I agree that it should be spelled out in the proposal, though.<br class=""></blockquote><br class="">That makes sense to me. Please explicitly add that to the proposal, thank you!<br class=""></blockquote><br class="">Done.</div></div></blockquote><br class=""></div><div class="">This really <i class="">isn’t</i> the model for @testable, as evidenced by the fact that top-level names in the testing module still shadow names from the imported module, and that you can refer to the name fully-qualified. Instead, the model is that @testable makes ‘internal' things ‘public'. I think this would make them ‘subclassable’/‘overridable’/‘open’ instead where relevant.</div></div></div></blockquote><div><br class=""></div>Right, sorry, I mis-spoke. The intent of @testable is to allow tests to have special privileges as if they were part of the same module, but of course it doesn't actually make them part of the same module, and there any number of lookup / redeclaration differences.</div><div><br class=""></div><div>Still, we're agreed on how that principle applies here: tests should be able to subclass / override things arbitrarily from the things they @testably import.</div><div><br class=""></div><div>John.</div></body></html>