RFC: seachsorted(a,x,by=f) no longer applies by to the key argument x

[krcools]

Following #9429, this pull request modifies searchsorted and friends to not apply to optional by argument to the sought for key x. As explained in #9429, this makes sense because it is not always possible to come up with a value x such that by(x) is the determinant is the binary search. In addition to the examples in #9429, consider a line of people ordered according to height. It is possible that a user is interested in the first person taller then 1.66 meters, even though no person in the line-up actually has that height.

The behaviour of searchsorted before these modifications can be achieved by calling

searchsorted(a,f(x),by=f)

The tests in test/sorting.jl have been modified to pass. In particular, consider:

@test searchsorted([1:10], false, by=(x -> x >=5)) == 1:4

Before, this test read

@test searchsorted([1:10], 1, by=(x-> x >=5)) == 1:4

This demonstrates how unnatural the previous behaviour was. The key 1 is arbitrarily chosen from the set of values that give by(x) == false. In addition, the previous behaviour obfuscates that in order for searchsorted to work correctly, it relies on the Julia convention false < true.

[StefanKarpinski]

I don't think this implementation will work well when combined with other ordering mechanisms. This all needs revisiting in light of jb/functions. The Ordering objects are no longer necessary – you can just pass in a comparison function directly, instead.

[krcools]

I'm not fixated on any implementation but I do think the semantics of searchsorted should change from what they are now to what is proposed above.

Could you refer me to the relevant issues/other reading on jb/functions?