Inconsistent order of arguments in variants of 'find'

[ttparker]

Most of the variants of find take the test predicate as the first argument and the array to be searched as the second argument (e.g. find(f::Function, A), findfirst(predicate::Function, A), findlast(predicate::Function, A), findnext(predicate::Function, A, i::Integer), findprev(predicate::Function, A, i::Integer)). But in the special case where the test predicate is a specific element value, this order of arguments is reversed (e.g. findfirst(A, v), findlast(A, v), findnext(A, v, i::Integer), findprev(A, v, i::Integer)). Should the order of arguments be made consistent?

@kshyatt

[simonster]

Related to #10593

[nalimilan]

indexin(a, b) also looks for a in b, which at odds with the A, v convention. As you say, I would find it more consistent, but also more natural, to use v, A. But I'm not sure how we could deprecate the existing forms and introduce the new ones without ambiguities or breakage. One solution would be to couple this change with plans from #10593, e.g. requiring an Order.Forward or Order.Backward argument for the new form until the old one is removed.

[ttparker]

I think I may have figured out the reason for why the arguments are reversed in the "specific-element search" version of these methods. Otherwise, if A were an array of functions and f were a specific function to search for, then it would be ambiguous whether the function call findfirst(f, A) meant "return the index of the first appearance of the function f within the array A", or "apply the function f to each element of the array A and return the index of the first element v such that f(v) == true".