Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update discussion about Equatable and Hashable in README after #56 #60

Merged
merged 1 commit into from
Sep 28, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 0 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -113,10 +113,6 @@ resilientRawRepresentableProperty

No. If you have a type that is generic over `<T>` and specify `@Resilient var someResilient: T` it will not matter if `T` is an array or dictionary, it will be treated as a single value.

### Why doesn't Resilient conform to `Hashable` or `Equatable` when its value does?

We believe that different consumers may have different understandings of what equality means for a `Resilient` type in the presence of errors. For instance, are two resilient properties equal if one recovered an error and the other decoded successfully? Depending on the use case, consumers may want to define equality differently and since it is fairly simple to define `Resilient` equality in an extension, we prefer to leave it to the consumer to decide.

### Why doesn't Resilient conform to `Encodable` when its value does?

We don't explicitly conform `Resilient` to `Encodable` because the encoding may be lossy in the presence of errors. If you are sure that this isn't an issue for your use case, it should be simple to provide an `Encodable` conformance in your own module.
Expand Down
Loading