[swift-evolution] [Draft] open and public protocols
Matthew Johnson
matthew at anandabits.com
Sat Feb 18 15:12:05 CST 2017
> 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.
>
> - Dave Sweeris
More information about the swift-evolution
mailing list