The core team has recently been discussing of a number of proposals that have been accepted but not implemented. You can see a list of these proposals on the evolution dashboard.
The core team feels that it's important to avoid a situation where evolution proposals remain accepted but unimplemented for long periods of time. The main cause of this was eliminated through the requirement that proposals come with an implementation prior to review. Some unimplemented proposals pre-date this rule. Another cause can be proposals that are implemented, but the implementation is not quite ready for production use. Finally, several proposals are mostly implemented, except for some small portion that proved problematic or was missed.
To resolve this, the core team has decided to make the following change to the evolution process:
All accepted proposals must have their implementation fully merged within one year of acceptance.
Proposals which are not implemented at all at that time will expire, and will require re-proposal.
Proposals which are partially implemented will have a "shrink to fit" approach applied, where the unimplemented parts will be removed from the proposal. This approach has already been taken with SE-0057.
Proposals which are accepted, but which have bugs relating to nuances in their implementation, but which aren't separable parts of the otherwise implemented proposal, will be treated as per the usual process for bug fixes in the language.
Any parts of a proposal that expire under this rule can of course be re-proposed, so long as this is done with an explanation of what caused the original proposal to expire and what is being done to avoid it happing again.
Given this, the following changes will be applied to the the list of accepted proposals:
SE-0153 is fully unimplemented and will be expired.
SE-0155 is partly implemented. The portion relating to changes to pattern matching behavior will be removed. There are also some bugs in the implementation (SR-12206 and SR-12229) which should be treated as existing bugs in the language.
SE-0163 proposed the addition of a Latin1 codec, but this was not implemented. This will be removed, and could be re-proposed via a stand-alone evolution proposal.
SE-0174 is mostly implemented, except for the addition of a Filtered associated type on Sequence (being previously blocked on recursive generic constraints). This aspect will be removed.
SE-0220 and SE-0246 are both unimplemented due to their impact on type checker performance. These could be reproposed once the type checker issues are addressed. Note that the full implementation of SE-0246 is available via the Numerics package.
SE-0283 is accepted but its implementation is not yet merged. It will be evaluated on the anniversary of its acceptance.
It looks to me like the implementations linked from both of these proposals have been merged—I don't think they belong in this list unless there's something I'm missing.
In the past when I've put a PR up to mark a proposal as "Implemented" it was indicated that such PRs should be delayed until we have a concrete Swift version number to attach to the "Implemented" status. Has this policy changed?
That makes sense. It should probably also be the practice that the "Accepted" status gets a date attached to it to make it easier to determine whether the anniversary has passed at a glance.
So in a way we are saying accepted with the condition of fully merged implementation within 1y. Otherwise Expired.
This timebox aspect should also apply to deferred and even rejected proposal. Something like after 2y, a deferred proposal needs to be re evaluated for further deferment or rejection.
A rejected proposal can be re-evaluated after 2y given enough interest and implementation.
Thanks for this clarification. I’ve mentioned this dissonance before, and am glad that we can finally say definitively that these won’t be implemented as-is.
Right. This distinction is important. We actively discourage relitigating rejected proposals, whereas we encourage new proposals that address the shortcomings of a deferred (e.g. good in principal but not acceptable in practice for reasons) proposal. I don't really see a motivation for expiring deferred proposals on a specific timeframe.
Much like projects that just automatically close bugs after a certain amount of time, I'm not sure this process actually improves anything beyond making a list somewhere look a little tidier. The usual way to amend an accepted proposal is to open a new discussion on Swift Evolution, outlining the reasoning behind the amendment and opening discussion about how best to address the issue. This can happen at any time, ideally as soon as issues are found.
While pruning away legitimately dead branches is reasonable, I’m concerned about an accepted proposal whose implementors are making an actual effort to implement it losing their approval for missing the deadline. Perhaps there should be an appeal process such that if an implementation is nearly at hand they don’t have to start over? Anything legitimately abandoned will have no champion to appeal for its extension.
I just don't think this scenario will happen often, nor should it be a concern if it does. As I mentioned in the post, implementations are a requirement for a proposal, so there are really only a few paths here:
Forgotten aspects of an implementation which are missed – in which case they were never truly vetted by the evolution process and ought to be subjected to further review. (there is maybe an argument that these features should not even get the year's grace for this reason, but that's perhaps going a little too far)
Poor quality implementations that just about cleared the functional bar, but were nowhere near ready to land and need significant work (and perhaps, may uncover serious reasons why the proposal was flawed). You can, in a sense, see the new policy as discouraging this: proposal implementations do not need to be fully good-to-merge, but they should be more than just a proof-of-concept.
Legitimate proposals with no flaws of their own, but where there is a fundamental issue uncovered (such as those blocked by the type checker). This is the most unfortunate case. But having a proposal stay in accepted state doesn't really help anyone – it just causes confusion. Wasn't this approved a year ago? Why can't I use this feature? It is better to be clear that this feature is just not coming any time soon despite being accepted.
I you want, you can think of the "appeal process" as being the ability to re-propose once the implementation is ready. I think it's reasonable to assume that the core team will never reject a previously approved proposal, with an implementation in which we are now confident, for some reason that was previously brought up in review and rejected before. We have been pretty firm in holding the line against re-litigation of settled matters. That applies just as much to re-proposals of previously accepted proposals as it does revisiting rejected proposals. So you should expect most re-reviews to be a fairly light exercise.
That said, a lot can change in a year+, and one of the reasons to expire these proposals is that what applied then may no longer apply now, so the core team feels it's appropriate to re-review these proposals to make sure they still make sense after such a long time.
I think it would be useful if there were a feedback step after a pitch has been developed, to decide whether the basic idea of a proposal is at least plausibly in line with the goals for the language, before substantial effort has been put into creating an implementation.
I am thinking in particular right now about the “typed throws” pitch, which saw significant push-back from many people, but its proponents are actively developing an implementation in the compiler.
If typed throws is not something the language wants at all, then we should decide that before people waste time and effort trying to implement it.
And if it is something the language wants, then it would also be good to decide that independently of any particular proposal for it.
This thought is not unique to any one proposal though, it is general for all pitches: there should be a step for deciding “is this worth pursuing and implementing”. It would not be for weighing in on the specifics of the proposal itself, but rather on the general idea behind it.
Is there any realistic path forward for SE-0220? It feels quite deadlocked at the moment — I haven't heard or seen any discussion of improving performance of operator overloads, a thread about an alternate solution raised legitimate concerns, and renaming seems to be out. Is there anything I can do to help make progress here?