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

[John McCall]

> On Jul 8, 2016, at 8:41 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> On Jul 6, 2016, at 09:16, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Jul 5, 2016, at 10:56 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>>> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution <swift-evolution at swift.org <mailto: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.

Right, sorry, I mis-spoke.  The intent of @testable is to allow tests to have special privileges as if they were part of the same module, but of course it doesn't actually make them part of the same module, and there any number of lookup / redeclaration differences.

Still, we're agreed on how that principle applies here:  tests should be able to subclass / override things arbitrarily from the things they @testably import.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/34211eb9/attachment.html>