> On Jul 5, 2016, at 10:56 PM, Chris Lattner <clatt...@apple.com> wrote: >> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution >> <swift-evolution@swift.org> 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. John. _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
