Revisit: SE-0030 Property Behaviors
Very cool feature, and will help implement new thinks after that! Including
async and await maybe!
Em ter, 8 de ago de 2017 às 13:23, Ted Kremenek via swift-evolution <
> 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:
> and a more persistent URL (invariant to future README.md changes):
> 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
> 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:
> 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 mailing list
swift-evolution mailing list