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.

  -- Howard.

On 9 August 2017 at 02:23, Ted Kremenek <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
>
> and a more persistent URL (invariant to future README.md changes):
>
>   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
>
> 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#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
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to