> On Aug 9, 2017, at 8:52 PM, Howard Lovatt via swift-evolution 
> <swift-evolution@swift.org> 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.


>   -- Howard.
> On 9 August 2017 at 02:23, Ted Kremenek <kreme...@apple.com 
> <mailto:kreme...@apple.com>> 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
> swift-evolution-annou...@swift.org <mailto:swift-evolution-annou...@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce 
> <https://lists.swift.org/mailman/listinfo/swift-evolution-announce>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
swift-evolution mailing list

Reply via email to