My 2c: Revisit: SE-0030 Property Behaviors <https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md>
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 < swift-evolution@swift.org> escreveu: > 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 mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution