# Tuple fields are still nuking Equatable

**URL:** <https://forums.swift.org/t/tuple-fields-are-still-nuking-equatable/85973>\
**Category:** Discussion\
**Created:** [April 12, 2026, 6:42pm UTC](https://forums.swift.org/t/tuple-fields-are-still-nuking-equatable/85973 "2026-04-12T18:42:38Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [April 12, 2026, 6:42pm UTC](https://forums.swift.org/t/tuple-fields-are-still-nuking-equatable/85973/1 "2026-04-12T18:42:38Z")

</div>

it’s just really, regrettably infuriating that adding a tuple field to a struct still breaks `Equatable` and `Hashable` synthesis for structs in Swift 6.3.

```swift
@frozen public struct DiminishingReturnBudget: Equatable {
// Stored property type '(dividend: Int64, buybacks: Int64)' does not conform to 
// protocol 'Equatable', preventing synthesized conformance of 
// 'DiminishingReturnBudget' to 'Equatable'
    public let l: TradingBudgetTier
    public let e: TradingBudgetTier
    public let x: TradingBudgetTier
    public let outflow: (
        dividend: Int64,
        buybacks: Int64,
    )

    public let ln: Int64
    public let en: Int64
    public let eH: Double
    public let eC: Double
}

```

i know that there has been a bigger effort to make tuples themselves conform to `Equatable`/`Hashable`, and that that effort has run into [well-publicized roadblocks](https://forums.swift.org/t/implementation-issues-with-se-0283-tuples-are-ehc/46946/2). but right now i just want to (re)raise the narrow, specific issue of tuple _fields_ breaking `Equatable` and `Hashable` synthesis.

surely this shouldn’t be blocked by the general problem of EHC for tuples?

---

<div class="post-metadata">

**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\
**Post date:** [April 13, 2026, 4:41am UTC](https://forums.swift.org/t/tuple-fields-are-still-nuking-equatable/85973/3 "2026-04-13T04:41:37Z")

</div>

well yes you can do that, but then you need shims for the nominalized fields and that’s a lot of boilerplate so people are tempted to try writing the `==(_:_:)` by hand. and that’s a decision that can come back to bite you much later if someone adds a field and forgets to update the `==(_:_:)`. it’s a bump in the road that leads some folks astray, and it would be a lot better if it weren’t there.

---

<div class="post-metadata">

**Author:** ![x-sheep](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/x-sheep/32/40748_2.png) [@x-sheep](https://forums.swift.org/u/x-sheep)\
**Post date:** [April 13, 2026, 12:23pm UTC](https://forums.swift.org/t/tuple-fields-are-still-nuking-equatable/85973/4 "2026-04-13T12:23:16Z")

</div>

The compiler could amend the synthesized `==` and `hash(into:)` functions with each individual tuple item, if a tuple is found. This would be a stop-gap solution until tuples themselves can conform to `Equatable` and `Hashable`, and this special behavior can be removed.

I'm very much in favor of this. Since the Evolution proposal for automatic tuple conformance to Equatable/Hashable is already approved, could this be done as a PR without going through the evolution process again?

---

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [April 13, 2026, 12:29pm UTC](https://forums.swift.org/t/tuple-fields-are-still-nuking-equatable/85973/5 "2026-04-13T12:29:27Z")

</div>

Proposal approvals expire after one year if their implementation hasn't been merged (or in the case of SE-0283, if it gets reverted).

The long-term goal is to have generalized tuple conformances, though implementation of this has had its own challenges. However, my understanding of previous discussions on the forum among the main compiler developers is that nobody is terribly interested in accruing more tech debt and special cases to graft half-measures onto the existing synthesis.