Perhaps I am too optimistic, and core team members correct me if I am speaking out of turn here, but…
I imagine that the core team will assist in providing implementations for proposals that are crucial to the progress of the language and/or highly popular — regardless of whether the proposal was authored by the core team or a community member. >From what I know of the team, they’re not going to let a good idea languish >just because of the name that’s in the author field. I’m sure they _are_ going >to strategically prioritize what gets attention, and that’s not a bad thing. Cheers, Paul > On Aug 8, 2017, at 12:40 PM, Adrian Zubarev via swift-evolution > <swift-evolution@swift.org> wrote: > > Thank you for the kind updates Ted. However I already feel the negative > impact because of the last restriction. I also would like to point out that, > personally I think until the swift-evolution is not moved to a forum this > will only create a great wall between proposal authors and people that are > capable of implementing the pitched functionality. However I see your point > there, I’ve also seen Slava Pestov pointing this out a couple of times > before, and I fully understand the main idea behind it. However, my main > point is that it would be really hard now to find volunteers who can > implement new functionality before we can even review something. For instance > we’ve got a quite complex proposal that didn’t made it in to Swift 3 in time > and was deferred from Swift 4, which aimed to fix metatypes in Swift. I can > only speak for myself and not the other two authors of our proposal, but I > won’t be able to provide an implementation for that proposal, because I’m not > a complier engineer and probably won’t become one any time soon. Long story > short the last restriction makes it really hard for me to participate in > swift-evolution process except for providing feedback in active reviews. > > > Am 8. August 2017 um 18:24:25, Ted Kremenek via swift-evolution > (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb: > >> 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 mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
