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

proposal: x/exp/xiter: add Compare/CompareFunc{2} #67455

Open
leaxoy opened this issue May 17, 2024 · 2 comments
Open

proposal: x/exp/xiter: add Compare/CompareFunc{2} #67455

leaxoy opened this issue May 17, 2024 · 2 comments
Labels
Milestone

Comments

@leaxoy
Copy link

leaxoy commented May 17, 2024

Proposal Details

Proposed to add below functions:

func Compare[E cmp.Ordered](x, y Seq[E]) int

func Compare[E any](x, y Seq[E], cmp func(E, E) int) int

Same as seq2

@gopherbot gopherbot added this to the Proposal milestone May 17, 2024
@borissmidt
Copy link

borissmidt commented May 18, 2024

Compare between two sequences seems to have a limited use. Because defining an order on a sequence can't be defined as a single implementation and thus is ambigue.

Here are a few options on how to implement the comparison:

What would you do if the sequences have different sizes?

Would the order of a sequence compared to another sequence be its compare of each element? Then parts of it is ordered before and others after.

Another option is to sum the elements of the sequence and then compare the value. Or maybe it would first average the sequence and compare them on that.

But in that case you would see the sequence as a set and ignore its order.

So having a generic compare function between sequences is very application and type specific.

So the best way to solve this problem is to let the user use map to do the element wise comparison.
The other comparisons can be created by using reduce and then compare the result.

@ianlancetaylor ianlancetaylor moved this to Incoming in Proposals May 18, 2024
@jimmyfrasche
Copy link
Member

@borissmidt presumably this would be the equivalent of https://pkg.go.dev/slices#Compare but over sequences instead of slices.

Otherwise I agree that sequences, while sometimes as reliable as slices, are more general and there are a lot of new ways for the input to be unkind. To safely use these you'd need to know that both inputs were "nice".

I'm not really for or against these but it makes me uneasy, like the xiter.Equals* from the original proposal. I'm all for these going somewhere but maybe somewhere third party until they've proven to be generally useful without causing problems or confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Incoming
Development

No branches or pull requests

4 participants