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

[Xiaodi Wu]

There's no way to make a source-breaking change non-breaking. A migration
path that meanders through several different designs just increases the
aggregate pain over multiple releases. The proposed migration path has the
great drawback that, even once approved, no person would actually be
allowed to write code that would compile under the final accepted design
until several versions in the future.

Either this issue about `open` protocols is so important that it meets the
bar for a source-breaking change in Swift 4 (see Ted Kremenek's post about
the very stringent criteria), and thus it merits a single discrete break in
source compatibility between Swift versions, or it is not sufficiently
important.


On Sat, Feb 18, 2017 at 4:44 PM, David Sweeris via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170219/fa23b010/attachment.html>