Update discussion about Equatable and Hashable in README after #56

[calda]

This section of the README is no longer necessary after #56.

[GeorgeLyon]

Sorry, I meant we should probably consider the rationale laid out in that comment with regard to adding those conformances directly in ResilientDecoding. But also, I'm not actively using this anymore so do what you think is right.

The risk here is if you have something like:

struct Foo: Equatable {
  @Resilient var bar: Int?
}
let firstFoo = try decoder.decode(Foo.self, from: """
  {"bar":"3"}
  """)
let secondFoo = try decoder.decode(Foo.self, from: """
  {"bar":"not 3"}
  """)
firstFoo == secondFoo // true, but "3" != "not 3"

[dfed]

The wrapped value in this example wouldn't be equal, though, would it? Since 3 != nil?

Certainly you could end up in cases where different errors are treated as equivalent, but at that point the underlying/wrapped value (nil) is indeed equivalent.

[GeorgeLyon]

The 3 wouldn’t decode because it is a string, sorry to make it confusing by picking a number.

My original position was that this was a design decision best left up to the user. If you look at a resilient type as equivalent to its non-resilient definition, then equating resilients makes sense. On the other hand, if you think about a resilient type as representing the original encoded entity, perhaps a little bit massaged to make decoding works, it no longer makes sense to have the “encountered an error” case be equal to the “didn’t encounter an error” case.