<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 18, 2017 at 4:44 PM, David Sweeris via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Feb 18, 2017, at 14:28, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br>
><br>
><br>
>> On Feb 18, 2017, at 3:52 PM, David Sweeris <<a href="mailto:davesweeris@mac.com">davesweeris@mac.com</a>> wrote:<br>
>><br>
>><br>
>>> On Feb 18, 2017, at 13:12, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br>
>>><br>
>>><br>
>>>> On Feb 18, 2017, at 3:01 PM, David Sweeris <<a href="mailto:davesweeris@mac.com">davesweeris@mac.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>>> On Feb 18, 2017, at 12:41 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>>>><br>
>>>>> ## Source compatibility<br>
>>>>><br>
>>>>> 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.<br>
>>>>><br>
>>>>> 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`).<br>
>>>>> 2. In Swift 4 (or 4.1 if necessary) start warning for `public protocol` with no annotation.<br>
>>>>> 3. In the subsequent release `public protocol` without annotation becomes an error.<br>
>>>>> 4. In the subsequent relase `public protocol` without annotation takes on the new semantics.<br>
>>>>> 5. `@nonopen` becomes a warning, and evenutally an erro as soon as we are comfortable making those changes.<br>
>>>><br>
>>>> 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?).<br>
>>>><br>
>>>> 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).<br>
>>><br>
>>> 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).<br>
>>><br>
>>> 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.<br>
>><br>
>> Do we need it for types? "@nonopen public class Foo {...}"?<br>
>><br>
>> (Serious question... I don't recall if we did this phased thing for open vs public types)<br>
><br>
> 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.<br>
<br>
</span>Ah! Ok, I can see that.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
- Dave Sweeris<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div>