This repository has been archived by the owner on Jul 22, 2024. It is now read-only.
Fallback hash methods if a struct is 100% ignored #40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
motivation
hashstructure has a slightly sharp edge in that if a struct contains only unexported fields, that it will hash to the same identity. This is undesirable because many structs contain only unexported fields, but semantically do not represent the same value to the user.
UseStringer
is not preferable for two reasons:explanation
this change keeps track of which fields are involved in computing a hash. If no fields from a struct are involved, then hashstructure will attempt to
.MashalBinary()
or.String()
and hash that instead.I put this behind a flag to maintain compatibility, but some default behaviour like this might be a good idea for a 3.x release.
note
I apologize for the formatting updates--my IDE styled it automatically.
If this request is accepted, I will revert the styling changes.