> On Jul 6, 2016, at 09:16, John McCall via swift-evolution > <[email protected]> wrote: > >> On Jul 5, 2016, at 10:56 PM, Chris Lattner <[email protected]> wrote: >>> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution >>> <[email protected]> wrote: >>> >>>> >>>> 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. >>> >>> 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. >> >> That makes sense to me. Please explicitly add that to the proposal, thank >> you! > > Done.
This really isn’t 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. Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
