> On Feb 18, 2017, at 13:12, Matthew Johnson <matt...@anandabits.com> wrote:
>
>
>> On Feb 18, 2017, at 3:01 PM, David Sweeris <daveswee...@mac.com> wrote:
>>
>>
>>> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution
>>> <swift-evolution@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)
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
