> On Jul 8, 2016, at 8:41 PM, Jordan Rose <[email protected]> wrote:
>> On Jul 6, 2016, at 09:16, John McCall via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> On Jul 5, 2016, at 10:56 PM, Chris Lattner <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
