During the design of the slices package ContainsFunc function was dropped at the time of discussion (#47203 (comment)). Briefly, the discussion was about the signature of the function and how often it is used.
I suggest finally making ContainsFunc, since we have Contains, so it will be consistent to have ContainsFunc as well. Also, it's just convenient to have such a function. Talking about the signature, for me, it's reasonable to make it the same as for IndexFunc: ContainsFunc[E comparable](s E, f func(E) bool) bool
I've created a PR for this change because I'm new here and didn't know that such change needs a proposal. In case you are curious – here it is: golang/exp#39
The text was updated successfully, but these errors were encountered:
As a tangent regarding "any", if we did want to add a function called Any in Go, I think it would be nice if we could make it return (T, ok) rather than just a bool, so that you can actually extract the thing that matches the predicate. Perhaps it would be
func Any[T any](x T, f func(T)bool) (T, bool)
or perhaps it would be
func Any[T, U any](x T, f func(T)(U, bool)) (U, bool)
The latter is most analogous to what Common Lisp calls 'some'.
Writing out those type signatures, I notice the collision between 'Any' and 'any', which have very different meanings. That makes me think maybe the function should have a different name. Maybe Some.
If anyone (someone?) wants to push further on this, feel free to file a separate proposal issue.
I appreciate the elegance of Any and All, but we have the analogy already set up: Index is to Contains as IndexFunc is to ___. The answer is clearly ContainsFunc. We should use the name people already familiar with the other APIs will expect if we're going to do this.
(In strings and bytes, we also have IndexAny and ContainsAny, which is something else entirely.)