[swift-evolution] [Draft] open and public protocols

[Matthew Johnson]

> On Feb 18, 2017, at 3:52 PM, David Sweeris <davesweeris at mac.com> wrote:
> 
> 
>> On Feb 18, 2017, at 13:12, Matthew Johnson <matthew at anandabits.com> wrote:
>> 
>> 
>>> On Feb 18, 2017, at 3:01 PM, David Sweeris <davesweeris at mac.com> wrote:
>>> 
>>> 
>>>> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> ## Source compatibility
>>>> 
>>>> This proposal breaks source compatibility, but in a way that allows for a simple mechanical migration.  A multi-release stratgegy will be used to roll out this proposal to provide maximum possible source compatibility from one release to the next.
>>>> 
>>>> 1. In Swift 4, introduce the `open` keyword and the `@nonopen` attribute (which can be applied to `public protocol` to give it the new semantics of `public`).
>>>> 2. In Swift 4 (or 4.1 if necessary) start warning for `public protocol` with no annotation.
>>>> 3. In the subsequent release `public protocol` without annotation becomes an error.
>>>> 4. In the subsequent relase `public protocol` without annotation takes on the new semantics.
>>>> 5. `@nonopen` becomes a warning, and evenutally an erro as soon as we are comfortable making those changes.
>>> 
>>> I don’t think we need @nonopen or warnings. IMHO, public/open should have the same semantics and syntax regardless of whether the declaration is a protocol or a concrete type (or a property?).
>>> 
>>> Other than that nit, I can’t think of a reason to oppose this. So… +1, because I like making things as consistent as possible (also because of the reasons in the motivation).
>> 
>> The purpose of using `@nonopen` for the migration is to eventually break people’s code if they don’t use the migrator and don’t annotate it.  If we don’t do that the library may ship a version that unintentionally breaks their clients (by continuing to use `public` after its meaning has changed).  
>> 
>> It’s better to break the library before it breaks any clients.  That will impact many fewer developers.  This can be handled automatically by the migrator and will be a relatively minor inconvenience for developers who don’t use it.  That’s better than allowing an accidentally bad version of a library from shipping.
> 
> Do we need it for types? "@nonopen public class Foo {...}"?
> 
> (Serious question... I don't recall if we did this phased thing for open vs public types)

No, because we already introduced that in Swift 3.  Swift 4 has a higher bar for breaking changes.  If the core team is willing to accept the proposal without a staged migration strategy I would not object to that.  But I believe it’s best for breaking proposals to present a staged migration strategy for the core team to consider.  That’s what this is.  I wouldn’t want lack of a staged migration strategy to sink the proposal.

> 
> - Dave Sweeris