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

[John McCall]

> 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!

Done.

John.