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.



> On Aug 8, 2017, at 12:40 PM, Adrian Zubarev via swift-evolution 
> <> 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 
> ( <>) 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 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 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 
>> manifesto:
>> <>
>> 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:
>> <>#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 mailing list
> <>
> <>
swift-evolution mailing list

Reply via email to