> On Feb 18, 2017, at 3:52 PM, David Sweeris <daveswee...@mac.com> wrote: > > >> 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)
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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution