> 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! -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
