[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

John McCall rjmccall at apple.com
Wed Jul 6 11:16:04 CDT 2016

> On Jul 5, 2016, at 10:56 PM, Chris Lattner <clattner at apple.com> wrote:
>> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution <swift-evolution at 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!



More information about the swift-evolution mailing list