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

[Jordan Rose]

> On Jul 6, 2016, at 09:16, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160708/b4a525eb/attachment.html>