[swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0177: Allow distinguishing between public access and public overridability

[Matthew Johnson]

> On Jul 27, 2016, at 8:36 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I brought this up in review, but there seems to be a serious testability problem here because of how special @testable is.
>> 
>> // This class is not subclassable outside of ModuleA.
>> public class NonSubclassableParentClass {
>>    // This method is not overridable outside of ModuleA.
>>    public func foo() {}
>> 
>>    // This method is not overridable outside of ModuleA because
>>    // its class restricts its access level.
>>    // It is not invalid to declare it as `open`.
>>    open func bar() {}
>> 
>>    // The behavior of `final` methods remains unchanged.
>>    public final func baz() {}
>> }
>> 
>> In a unit test, I *can* subclass `NonSubclassableParentClass`, the access level of `NonSubclassableParentClass` is irrelevant. There’s now no programatic way to ensure that I’m actually testing the contract that I had intended to provide to the consumers of my framework (that my class is subclassable). Is this really the intention?
> 
> I could be wrong, but isn't `@testable import` applied per-file? So if you keep code users should actually be able to write in one file with a non-`@testable` import, and mocks and other testing hacks in a different file with an `@testable` import, the first file should fail to compile if you use anything that's not normally permitted.
> 
> In a future version of Swift, we might consider refining this by requiring people to apply `@testable` directly to declarations which treat something closed as if it's open, but it seems like even the current feature set does not make testing impossible.

+1 to @testable on declarations.  I really do not like making things internal when they should be private just because a test needs to inspect state.

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution