I like the old behavior. It makes for easy error checking in loops, so you don't have to unpack multiple values awkwardly. Adding the bool seems unnecessary to me, when =-1 will turn the result into a bool. Furthermore, these functions have -1 as "could not find" in most languages I have encountered, so it makes it easier for people coming from other languages.

Adding the bool seems unnecessary to me, when =-1 will turn the result into a bool. Furthermore, these functions have -1 as "could not find" in most languages I have encountered, so it makes it easier for people coming from other languages.

That theory doesn't explain sort.Search and its family.

https://golang.org/pkg/sort/#Search

If there is no such index, Search returns n. (Note that the "not found" return value is not -1 as in, for instance, strings.Index.)

The note implies that always assuming -1 as the "not found" value is a common mistake.

If we can make type signatures more descriptive, we won't see those kind of mistakes.

The functions as they are today work fine. Rewriting will make many uses more complex, as it will be necessary to use variables in a separate statement rather than just an expression. Currently these functions return an invalid index on failure, and using it will fail. If we change to the standard convention, we would return zero on failure, which is a valid index. We would probably instead prefer to continue to return an invalid index, making it more complicated. There are arguments on both sides, so let's keep things they way they are.