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

Right. So IIUC, what you called a serious testability issue earlier in the thread (inadvertent open inside public) is no more and no less an issue with @testable than inadvertent sealed inside open (in that neither would be picked up during such testing), and proper black box testing is what you

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

> On Jul 27, 2016, at 8:52 PM, Xiaodi Wu wrote: > > On Wed, Jul 27, 2016 at 10:30 PM, David Owens II via swift-evolution > > wrote: > > > On Jul 27, 2016, at 7:18 PM, John McCall >

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

On Wed, Jul 27, 2016 at 10:30 PM, David Owens II via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jul 27, 2016, at 7:18 PM, John McCall wrote: > > > > > >> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution < > swift-evolution@swift.org> wrote: >

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

> On Jul 27, 2016, at 7:18 PM, John McCall wrote: > > >> On Jul 27, 2016, at 6:55 PM, David Owens II via swift-evolution >> wrote: >> >> Yes, it’s per file. It’s also added in the initial template that Xcode >> creates with your project. In

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

Yes, it’s per file. It’s also added in the initial template that Xcode creates with your project. In addition, it’s recommended by many that talk about “how to unit test in Swift.” So, to someone that is not paying scrupulous attention, there is no mechanism to prevent against this today. This

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

I’m a bit confused here… Since the result of breaching your subclassing contract is a compile-time error, how are you intending to test that using XCTest? On the other hand, if you want to write a test that subclasses the class, and uses it as a Library consumer would, why would you use

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

> On Jul 27, 2016, at 8:47 PM, Brent Royal-Gordon > wrote: > >> On Jul 27, 2016, at 6:43 PM, Matthew Johnson wrote: >> >>> In a future version of Swift, we might consider refining this by requiring >>> people to apply `@testable` directly to

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

> On Jul 27, 2016, at 6:43 PM, Matthew Johnson wrote: > >> 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

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

> On Jul 27, 2016, at 8:36 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution >> wrote: >> >> I brought this up in review, but there seems to be a serious testability

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

> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution > 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. >

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

Other than warning on open methods in non-open classes, I can’t think of a good way to avoid this and still preserve the rest of the testing model. After all, @testable allows you to override internal methods too. (Just to make things clear, @testable only applies to the current file, so it’s

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

While arguably true, that's a philosophical debate. There are plenty of reasons to use @testable, and if that's what people are using, then I think there is a valid concern here. Sent from my iPhone > On Jul 27, 2016, at 5:22 PM, John McCall wrote: > >> On Jul 27, 2016,

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

> On Jul 27, 2016, at 4:41 PM, David Owens II via swift-evolution > 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. >

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

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

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

I realize that there’s no review needed, but I actually wanted to give a hearty  to the authors and commenters of this proposal, because I genuinely think we’ve reached something good in the result. The selling point for me is this: // This is allowed since the superclass is `open`. class