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

Ignore order when comparing equality of slices/maps #28

Closed
alenkacz opened this issue Jun 18, 2019 · 7 comments
Closed

Ignore order when comparing equality of slices/maps #28

alenkacz opened this issue Jun 18, 2019 · 7 comments

Comments

@alenkacz
Copy link

It would be great to have option to ignore order of items in slices/maps and just assert that it contains the same element.

@daniel-nichter
Copy link
Member

Can you give an example of what you'd like to see for both? Order shouldn't matter for maps, but it's inherent to slices.

@bdandy
Copy link

bdandy commented Oct 8, 2019

I think there should be an option for slices; sometimes order is matter; sometimes doesn't. But maps are unordered by default

@tatemz
Copy link

tatemz commented Jan 4, 2021

+1 for this

I have a use case where I am testing a slice that results from go routines and the order varies.

Maybe the method signature can use flags?

Equal(a, b interface{}, ...flags interface{})
deep.Equal([]string{"hello", "world"}, []string{"world", "hello"}, deep.FLAG_IGNORE_SLICE_ORDER) 

@benjamin-rood
Copy link

benjamin-rood commented May 5, 2022

Order shouldn't matter for maps, but it's inherent to slices.

It's inherent to the data structure, but not inherent from the perspective of the user. Sometimes people use slices as an unordered list, sometimes they use them as ordered lists.

If you are dealing with a lot of data mangling and manipulation because of the restrictiveness of Go's type system (and it will be years before most libraries switch to using implementation with generics now that 1.18 has come out), then it's a massive pain point.
Currently, I have to copy the deeply-nested slices inside two structs I am comparing, sort both, then overwrite the sorted slices with what was originally there, before I can call deep.Equal. That alone is a good enough use case.

A case in point is the generated go code from Protobuf definitions, which can be an absolute nightmare to deal with if you need to do any kind of validation between definitions in separate files, especially when the underlying values of the objects being compared are absolutely identical.

If you look at the stretchr/testify library, the decision was made over time to switch to an unordered comparison. Sadly, that library is not valid for comparing deeply-nested objects. I would like to do the work on a PR implementing @tatemz suggestion, that it be an optional argument to Equal.

@daniel-nichter
Copy link
Member

It's been a few years, but better late than never: implemented in #56 and will be released as v1.1.0 since it's a relatively major addition even though it's backwards compatible.

@benjamin-rood
Copy link

It's been a few years, but better late than never: implemented in #56 and will be released as v1.1.0 since it's a relatively major addition even though it's backwards compatible.

Thank you, Daniel!

@daniel-nichter
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants