I have also encountered this issue before. I agree it's annoying. Sometimes I have to create a temp element simply to make the comparison works, while all I really care is just a member value of that element.

But if backwards compatibility is not a problem, maybe changing the signature to

func BinarySearchFunc[E any](x []E, cmp func(E) int) (int, bool) 

would be enough and simpler? the target can be captured into the cmp function anyway.

I suggested that in the original issue but it did not happen. Perhaps my arguments at the time where weak, though.

I support this proposal. For the same reasons I gave in the original proposal, I'm not keen on the one-argument form, because it's not clear which way the comparison goes (and if anyone else is similar to me, it's can be a real brain bender to work out exactly which is correct), and in practice you'll always end up creating a closure.

As an example, say we have a slice of objects ordered by time. Using the more general API is nice here:

type entry struct {
	key string
	val int
}

func (e *entry) cmpKey(k string) int {
	return strings.Compare(e.key, k)
}

func findEntry(es []*entry, k string) *entry {
	i, ok := slices.BinarySearchFunc(es, k, (*entry).cmpKey)
	if ok {
		return es[i]
	}
	return nil
}

My preference is for the closure, one argument form. In the cases where you do use a closure instead of a method, the two argument form ends up being confusing in its own way.

I think the one argument version is the most consistent with sort.Search, but I think the two argument version gives the most flexibility by allowing for the use of non-closure arguments. I think it's clear what the arguments are and what the return value is. I am also in the boat where I'm left scratching my head about what to write inside a 1-ary cmp function, and I get sort.Search wrong often enough that I nowadays always look up an example.

It sounds like people are generally in favor of

func BinarySearchFunc[E, T any](x []E, target T, cmp func(E, T) int) (int, bool)

Is E, T the standard order in other languages for the comparison arguments in a call like this?

Are there any other concerns?

Is E, T the standard order in other languages for the comparison arguments in a call like this?

These are the closest equivalents I can find in other languages:

Python: bisect
Java: For arrays and Lists

They each take the slice-equivalent first and the target element second, like the proposed BinarySearchFunc, and presumably the cmp function should take its arguments in the same order.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Change https://go.dev/cl/464456 mentions this issue: slices: allow different types in BinarySearchFunc

Change https://go.dev/cl/485995 mentions this issue: slices: update BinarySearchFunc docs for CL 464456

Change https://go.dev/cl/498395 mentions this issue: doc/go1.21: merge x/exp/slices issue into slices package