compnerd
May 19, 2020, 8:03pm
1
The review of SE-0283 has concluded.
Almost all the feedback we received was positive, and the Core Team is convinced that this is a great incremental step forward. Some excellent points on possible concern over future tech debt in the compiler and runtime were brought up, but the Core Team believes that it is manageable and that this proposal helps push Swift forward in a positive direction.
SE-0283 is accepted .
Thank you for your contributions to Swift.
Saleem Abdulrasool
62 Likes
Question, I donât mean to be a bother, but I read that if proposals are not implemented within a year, they are no longer accepted, and itâs been over a yearâŚor has the guidance changed?
2 Likes
mackoj
March 9, 2022, 12:50am
3
It will soon be 2 years since this feature has been accepted. Should we consider it now has rejected ?
Jumhyn
March 9, 2022, 1:07am
4
The standing rule, I believe, is that if proposals are not implemented within 1 year of acceptance, they revert to âunreviewedâ and must go through evolution again. Unless this has changed?
1 Like
Panajev
March 9, 2022, 6:17am
5
Hello @Joe_Groff @Alejandro @tkremenek the implementation PR for this proposal was merged and then reverted in 2020 and then a draft PR appeared again in 2021, do you know if it had been reimplemented or? Sorry for the nudge, but is there any update please?
apple:main â Azoy:void-is-equatable
opened 06:38PM - 17 Dec 19 UTC
From: https://forums.swift.org/t/hacking-equatable-conformance-on-void/25975
⌠The tests right now are kind of lackluster, what else can I be testing with this? What else can be improved upon in this implementation? Is there an edge case that I hadn't thought about?
cc: @jckarter @rjmccall
apple:main â Azoy:revert-se-0283
opened 05:46PM - 29 Oct 20 UTC
Hopefully I did this right...
apple:main â Azoy:tuples-are-friends-not-food
opened 03:55AM - 13 May 21 UTC
This is another attempt to getting tuples to conform to these protocols. I made ⌠some very different choices when implementing this one to prevent the usage of assembly to create these conformance data structures. Notably, the only real changes should be in `BuiltinProtocolConformances.h` and the respectful `BuiltinProtocolConformances.cpp`. This approach creates placeholders for relative references instead of using assembly to create relocations. On startup, we setup the relative references to their respectful offsets. Because the assembly we needed to make had to make use of dynamic relocations like `@GOT` (because LLVM won't let us reference undefined symbols right now), there had to be startup overhead for the dynamic linker to figure out the relative references anyway, so I figured that performance characteristics would roughly be about the same.
Right now, I haven't implemented any of the compatibility stuff because I wanted to get a feel for whether or not this approach was worth looking into. In terms of the stub needed for back deployment, the best solution I could come up with was to reference `swift_conformsToProtocol` to get the witness table when back deploying. This is great for older clients because they instantly get the witness table that's already created within the compatibility library, but the Swift current suffers in that it now needs to search for the witness tables of its elements. Obviously if we're not back deploying we can simply stick with `swift_getWitnessTable` and reference the conformance descriptor directly.
Please let me know what you think about this approach or if you had any other ideas! I really want people to get their hands on this feature, but I also want a solution that is sustainable (at least until actual non-nominal conformances come, then we can rip most of this out).
Edit: Alternatively, instead of a constructor that sets up all of these references, we could lazily set up each conformance descriptor when they're being used in either `swift_getWitnessTable` or `swift_conformsToProtocol` (if we choose to use that as a stub).
2 Likes
This feature is particularly complicated to implement completely. Some foundational bits in the compiler and runtime are improving and would make it easier, but there is no update on when it will be fully implemented.
Doug
5 Likes
scanon
March 10, 2022, 1:05am
7
Should we update the proposal status to reflect that reality?
8 Likes
It also seems that once proposal implemented again it should also include Sendable in the list of automatically synthesized protocols.
1 Like
awwright
October 2, 2025, 5:03pm
9
Why is this proposal still showing as "Accepted"?
I thought this meant I should be able to use the feature , but apparently that's not the case? Is it stuck on another task?
Jumhyn
October 2, 2025, 5:05pm
10
I think it would be appropriate to update this proposal to "expired"âthere were implementation issues which prevented the feature from shipping and it's been well over the 1 year threshold.
4 Likes
tevelee
October 2, 2025, 5:34pm
11
Slava had a genius proposal a while back to allow user defined tuple conformances using parameter packs
Slava Pestov
Status: Implementation in progress
Upcoming Feature Flag: TupleConformances
Previous Proposal: SE-0283 Tuples Conform to Equatable, Comparable, and Hashable
Review: (pitch )
2 Likes