[Accepted] SE-0283: Tuples conform to Equatable, Comparable, and Hashable

compnerd · May 19, 2020, 8:03pm

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
Review Manager

Judgeman777 · July 16, 2021, 4:37am

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?

mackoj · March 9, 2022, 12:50am

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

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?

Panajev · March 9, 2022, 6:17am

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?

github.com/apple/swift

[SE-0283] Implement Equatable, Hashable, and Comparable conformance for tuples (again)

apple:main ← Azoy:tuples-are-friends-not-food

opened 03:55AM - 13 May 21 UTC

Azoy

+1642 -69

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).

Douglas_Gregor · March 10, 2022, 12:30am

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

scanon · March 10, 2022, 1:05am

Should we update the proposal status to reflect that reality?

yyarashevich · November 18, 2022, 3:31pm

It also seems that once proposal implemented again it should also include Sendable in the list of automatically synthesized protocols.