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

[David Sweeris]

> On Feb 18, 2017, at 14:28, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> 
>> 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.

Ah! Ok, I can see that.

Well, for whatever my opinion is worth, I'd prefer we left that part out. But I'd rather leave it in than for the proposal to get rejected, though.

- Dave Sweeris