> On Aug 9, 2017, at 8:52 PM, Howard Lovatt via swift-evolution > <[email protected]> wrote: > I am not against these changes, of requiring an implementation, but I am a > little nervous. Let me expand. > > I was involved in the Java Coin initiative for community driven changes to > Java 7. In that process the implementation barrier was set very high and it > effectively meant that only changes from Sun got through, a number of people > put considerable effort in only for the proposals to be rejected. I felt the > process was in the end a little disingenuous and I think that view was held > by many, perhaps tellingly the process has never run again for subsequent > Java versions. > > So my cautionary note is that this requirement of implementation requires > careful stewardship and in particular there needs to be some means of getting > 'in principle' approval before the implementation stage. If done correctly it > could work very well.
This seems very sensible to me. Certainly we would want some way of flushing out "in principle" concerns before too much implementation time gets spent. John. > > -- Howard. > > On 9 August 2017 at 02:23, Ted Kremenek <[email protected] > <mailto:[email protected]>> wrote: > Hi everyone, > > The proposal phase for Swift 4 is now officially over, and the release is now > in endgame engineering convergence for an expected release later this year. > Swift 4 has turned out to be one of the highest quality, well-rounded > releases of Swift, and I am grateful to everyone in the community who made > this release come together! > > Now it is time to turn our attention to Swift 5. I have just posted updates > to the README.md file on the swift-evolution repository, which outlines the > core themes and focus areas for Swift 5: > > https://github.com/apple/swift-evolution > <https://github.com/apple/swift-evolution> > > and a more persistent URL (invariant to future README.md changes): > > > https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md > > <https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md> > > I am not going to repeat all of that information here, but I wanted to > highlight a few important things. > > ## ABI Stability > > First, ABI stability is the center focus of Swift 5 — and we will pivot much > of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI > stability was a strong goal. In Swift 5, it is a *requirement* of the > release. Whatever ABI we have at the end of Swift 5 is the ABI that we will > have. ABI stability is an important inflection point for the maturity of the > language, and it cannot be delayed any longer. > > Please note that there is a difference between ABI stability and module > stability. If you are not aware of the difference — which is rather > important — please read the first few paragraphs of the ABI stability > manifesto: > > https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md > <https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md> > > Module stability is a stretch goal for Swift 5, but even without module > stability we can still achieve the primary value of ABI stability. > > ## Other focus areas (including laying the groundwork for concurrency) > > There are several other areas mentioned for Swift 5 which I won’t repeat > here, but there is a general theme of refining and broadening out the core > ergonomics of the language and standard library. > > One of those that I wanted to highlight is laying the groundwork for > concurrency. It is a non-goal of Swift 5 to roll out a full new concurrency > model. That is simply too large an effort to do alongside ABI stability. > However, it is important that we start making progress on discussing the > directions for concurrency and laying some of the groundwork. This may take > the form of specific enhancements to the language that get implemented, > depending on where the discussions for concurrency lead and how they align > with the priorities for delivering ABI stability in Swift 5. > > ## Changes to the language evolution process > > Last, I want to highlight important changes to the evolution process: > > https://github.com/apple/swift-evolution > <https://github.com/apple/swift-evolution>#evolution-process-for-swift-5 > <https://github.com/apple/swift-evolution-swift5-goals#evolution-process-for-swift-5> > > With Swift 4, the release period was divided up into “stage 1” and “stage 2” > for setting guidelines for the kind of evolution proposals that were in scope > for the release. This was needed to establish focus — especially after the > churn we saw during Swift 3 — on some core themes that were aligned with > converging the language towards source & ABI stability. One downside is that > “stage 2” opened up discussion for potentially disruptive changes fairly late > in the release. Further, some proposals — such as SE-0155 — came in so late > that there was little runway to actually implement them for Swift 4, let > alone evaluate their impact in practice on real projects. Related, there has > been some desire for a while to be able to better evaluate the impact of > proposals on real code before they are locked into the release, and the best > way to do that is to actually have an implementation that vets out the design > in a proposal. > > With Swift 5, the focus on ABI stability will predominate priorities for both > design and implementation work, but the Core Team did not want that focus to > stifle all discussion on potential enhancements to the language that were not > fundamentally tied to that primary goal. After reflecting on the evolution > process during both the Swift 3 and Swift 4 releases, the Core Team felt that > we could strike a balance with not diluting attention from ABI stability > while still enabling a broader range of proposals compared to Swift 4 by > **requiring that all proposals have an implementation** before they are > officially reviewed by the Core Team. An implementation can come long after > an idea has been pitched and after a proposal has been written. However, > before a pull request for an evolution proposal will be accepted — and thus > an official review scheduled — an implementation must be in hand for a > proposal as part of the review. The existence of an implementation does not > guarantee that the proposal will be accepted, but it is instrumental in > evaluating the quality and impact of the proposal. > > There are two key benefits of requiring an implementation: > > 1. It encourages a design in a proposal to be more thoroughly fleshed out > before the proposal is formally reviewed. The hope is that this will make > the review process both more efficient as well as more effective. > > 2. An implementation allows the proposal to be evaluated on real world code > and not just the examples that are in the proposal. > > The Core Team is also sensitive to proposal authors investing time in > providing an implementation for a proposal that is not likely to get > traction. The Core Team will be regularly reviewing potential proposals, and > provide feedback either during the pitch stage or when a proposal is > submitted via a pull request on whether or not the proposed change looks > within the charter of the release or meets the criteria for a valuable change > to the language. > > Requiring an implementation naturally raises the bar for proposals. While > this is by design, it can possibly have the negative aspect of making some > feel the bar is too high for them to participate in the Swift evolution > process. As an open source project, both the design and implementation of > the language is a highly social endeavor, and we encourage the community to > collaborate on both the design and implementation of proposals. > Specifically, it is not a requirement that the original author(s) of a > proposal be the one who provides an implementation — all that matters is that > there is an implementation when a proposal gets reviewed. > > Lastly, an important aspect is that unlike Swift 4, the broadening of scope > for proposals considered for Swift 5 begins… now! Proposals that fit within > the general focus of the release are welcome until March 1, 2018. Proposals > will still be considered after that, but the bar will be increasingly high to > accept changes for Swift 5. > > - Ted > > _______________________________________________ > swift-evolution-announce mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution-announce > <https://lists.swift.org/mailman/listinfo/swift-evolution-announce> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
