Tuple fields are still nuking Equatable

Evolution Discussion
1

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.

@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. 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?

11 Likes
2

Swift does not use the terminology "field".

You can just tell Claude to nominalize 'em.

@frozen public struct DiminishingReturnBudget: Equatable {
  public let outflow: Outflow
  public struct Outflow: Equatable {
    var dividend: Int64
    var buybacks: Int64
  }
}
3

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.

7 Likes
4

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?

5

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.

3 Likes