Impact of @ObservableState on a state type's Equatable and Hashable conformances

[wltrup]

Hi Brandon and Stephen,

ever since your first video on adding identity to value types, I've been wondering about the potential impact of the added identifier on a state type's conformances to Equatable and Hashable. If I understand correctly, the only reason for the state type to be Equatable is to support testing, in which case I assume you will handle internally any potential impact of the added identifier.

However, what if someone needs the state to be Equatable and/or Hashable for their own reasons? Then two instances of the state - with the same data (other than their identifiers) - are not going to be equal despite the fact that, as far as the user of the Composable Architecture library is concerned, the two instances should be identical in that scenario.

I don't have any specific example in mind but it is something that's puzzling me because it's a gotcha! waiting to happen and I'm wondering if you have thought about that problem.

As always, many thanks for the great work you're doing for the Apple developer ecosystem and for reading and answering people's questions.

[stephencelis]

@wltrup @ObservableState adds a special kind of observation registrar to your type, and this type is what holds onto an identifier, but like the observation registrar that comes with Swift's Observation framework, it is trivially equatable/hashable/codable and so the identity of a piece of state is not included in the equality/hashing of said state. And so I don't think @ObservableState introduces anything new to consider here. You should be able to approach the problem the same way now as you would in the past.

As a side note we did explore factoring the observable identity into equatability, but found that it made testing more difficult and went against the grain of how folks expect to equate values.

[wltrup]

Hi @stephencelis, thanks for the quick reply. I understand what you're saying and I see how it avoids the problem I was worried about but I'm a little puzzled now because in your latest video you (or, rather, the @ObservableState macro) explicitly add the identifier to the state type itself, not to the observation registrar. Am I correct in assuming that you did that in the video just to keep things simple but, in the final version of the library, the identifier will actually live inside the observation registrar?

Many thanks again.