Addressing unimplemented evolution proposals

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.

3 Likes

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.

1 Like

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.

3 Likes

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.

5 Likes

Here’s something of a tangential remark:

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.

12 Likes

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?

4 Likes

That thread didn’t get a ton of traction, but I wouldn’t call it dead. I think it may still be possible to come to a consensus.

Ben, whatever happened with this Core team guidance from September 2020? There are still over a dozen unimplemented proposals, half of which are growing quite old. When will the one year cutoff take place for proposals that have not been implemented, or has the guidance changed?

One thought I had was that any proposals that are over a year old can be “returned for revision” as opposed to rejected. Is anyone going to comment on this? The core team created this discussion and seemingly abandoned it without a word.

2 Likes

@benrimmington @tomerd Whats the status on the 5 Accepted Evolution proposals that are a year + un-implemented? I ask because I feel it’s good to keep drawing attention to these proposals to give them renewed vigor and maybe help them get implemented or not:

SE: 0220 count(where:) = 3 years 8 months
SE: 0246 Generic Math(s) Functions = 3 years
SE: 0274 Concise magic file names = 2 years 1 month
SE: 0283 Tuples Conform to Equatable , Comparable , and Hashable = 1 year 11 months
SE: Package Editor Commands = 1 year 1 month

What are their statuses, frozen? Any implementation goal time? Just curious! :slight_smile:

3 Likes

Evolution is mainly about reviewing language proposals rather than discussing implementations, so this is not really the right place to be asking about updates on implementation time frames. Please don’t use this thread as a general place to ping for fresh updates on implementation of expired proposals. The guidance remains that if implementations of expired proposals become available these proposals would need to be re-run (though that ought to be a fairly lightweight process).

1 Like

The core team decided to reject the expired proposals, but that hasn't happened yet.

(SE-0274 might be withdrawn, because it was superseded by SE-0285.)

Right. The main problem here is representing these on the dashboard/in the proposal doc as “Rejected” kind of implies that these proposals were turned down as not a good idea, but in most (though not all) cases, the acceptance holds in principal but they couldn’t actually land for some unexpected reason, and since too much time has passed, they should be re-evaluated if those blockages are cleared.

But this is most a question of “how should we represent their status on the dashboard” rather than “when are they coming”. How long it’s been and what’s going on about fixing the blockers isn’t relevant to that.

2 Likes

Sorry! Had no idea they had all been rejected. Good to know.

Maybe label them as expired?

6 Likes

@Ben_Cohen @benrimmington I mean, that's gotta be the answer right? A new "expired" category would eliminate confusion.

From the dashboard/status side of things, there's nothing really stopping us from adding a new state or presentation for these proposals, other than consensus that it should it exist and what we should call it.

1 Like

I think this is the very discussion which is relevant:

Quoting:

tkremenek commented on 27 Oct 2021

We will require new proposals for "expired" proposals, but we will represent them by "rejected" instead of "expired", with a commentary added from the core team saying the proposal was expired.

3 Likes

Guess that’s the answer! When is that going to happen?