Note that 0283 is no longer accepted

[awwright]

No description provided.

[awwright]

This proposal seems to have fallen into an exceptional state where it's "accepted" but not being implemented. This has caused much confusion, e.g.

https://forums.swift.org/t/accepted-se-0283-tuples-conform-to-equatable-comparable-and-hashable/36658/10
https://forums.swift.org/t/status-of-se-0283-tuples-conform-to-equatable-comparable-and-hashable/46942
https://forums.swift.org/t/why-isnt-my-int-int-hashable/82400

I'm not able to find any process that describes what to do in this situation, but it probably shouldn't be sitting around as "Accepted"

[xwu]

I believe the status we assign to such proposals is "expired"—because these fields are parsed by various tooling, they're not really freeform anymore and it's possible we've been labeling them "rejected." In any case, an announcement on the status change is due as well.

[ole]

It looks like "expired" is not a formal status we're assigning to proposals.

The Swift Evolution metadata extractor (maintained by @dempseyatgithub) doesn't know the status "expired". See https://github.com/swiftlang/swift-evolution-metadata-extractor/blob/main/Sources/EvolutionMetadataModel/Proposal%2BStatus.swift

---

This 2021-10 comment from @amartini51 says the Core Team decided against an "Expired" status:

For some old proposals, after they were approved, the rest of the language and ecosystem has changed in ways such that we wouldn’t approve them today. But others are proposals that are challenging to implement and have ongoing work towards building them, and are still a good idea even though they’re older. We need to treat those two categories differently. An automated one-year expiration doesn’t serve that goal — we need to be able to make an assessment of whether there’s forward movement on the implementation. So we wouldn’t want to mark proposals as Expired just by doing date math on the dashboard.

To preserve the meaning of the proposed Expired state, a proposal shouldn’t move into Expired and then later come back and get implemented. Allowing that un-expiration would essentially make Expired just a different “flavor” of Accepted without providing additional information to folks reading it.

Likewise, if we use Expired as a final state for proposals that won’t become part of the language, we already have a name for that: Rejected.

@tkremenek in the same thread: #1451 (comment)

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.

---

@airspeedswift originally introduced the idea of expired proposals in this post: Addressing unimplemented evolution proposals (2020-09-15)

• The one proposal named as "expired" in that post today has the status "rejected": SE-0153

• Other proposals listed as unimplemented in that post:

  • SE-0220: count(where:)
    • SE-0220 has the status "Implemented" after it has been re-reviewed and re-accepted a second time. Before that, it was listed as "Accepted" for years, similar to SE-0283 today.
    • Arguably, it should have been marked as "rejected" and re-proposed as a new proposal if the process outlined by @tkremenek in 2021 had been followed to the letter?
  • SE-0246: Generic Math(s) Functions
    • Is still listed as "Accepted with modifications (2019-03-28)". I don't know what to make of this.

---

Coming back to SE-0283, @slavapestov recently said that the proposal will probably not come back in its original form. Slava Pestov (2025-11-09):

Now that we have [[Parameter packs|parameter packs]], the old plan of hard-coding certain tuple conformances directly in the compiler is obsolete. A more recent pitch that reflects the current plan is here: Pitch: User-defined tuple conformances

This suggests to me the status for SE-0283 should be "Rejected".

[rjmccall]

The LSG decided to make it Returned for Revisions.