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

[Brent Royal-Gordon]

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

-- 
Brent Royal-Gordon
Architechies