Add `findfirstvalue(f, itr)`

[CameronBieganek]

EDIT: Title changed base on feedback from @nlw0.

I often find myself wishing that we had a version of findfirst(f, A) that just returned the first x for which f(x) is true, rather than returning the index. Granted, you could just write that as A[findfirst(f, A)], but that's less elegant for long array names, like

very_long_name[findfirst(f, very_long_name)]

Furthermore, findfirst(f, A) does not work for arbitrary iterators:

julia> itr = Iterators.drop(1:8, 4)
Base.Iterators.Drop{UnitRange{Int64}}(1:8, 4)

julia> findfirst(isodd, itr)
ERROR: MethodError: no method matching keys(::Base.Iterators.Drop{UnitRange{Int64}})

We do have the following option,

julia> first(Iterators.filter(isodd, itr))
5

but that's somewhat bulky. So, I propose that we add first(f, itr), which should work for arbitrary iterators. While we're at it, I suppose we should also add first(f, itr, n::Integer). That would be expected to return an array, since first(itr, n) returns an array:

julia> first(itr, 2)
2-element Vector{Int64}:
 5
 6

So, I suppose if one wanted first(f, itr, n) to return an iterator, they would have to use the following instead:

julia> Iterators.take(Iterators.filter(isodd, itr), 2)
Base.Iterators.Take{Base.Iterators.Filter{typeof(isodd), Base.Iterators.Drop{UnitRange{Int64}}}}(Base.Iterators.Filter{typeof(isodd), Base.Iterators.Drop{UnitRange{Int64}}}(isodd, Base.Iterators.Drop{UnitRange{Int64}}(1:8, 4)), 2)

julia> Iterators.take(Iterators.filter(isodd, itr), 2) |> collect
2-element Vector{Int64}:
 5
 7

[nlw0]

To me it sounds a bit like a big change in semantics. first merely takes the first element. Why wouldn't that stand for first(map(f, A))?

It's understandable that findfirst doesn't work for iterators, because it returns and index... Maybe we should have something like a findfirstval? Or maybe it could take a value=true argument.

Actually, the name find seems to be available, but feels like a big step to take it. Still, seems more adequate than first.

[CameronBieganek]

There are quite a few functions in Base Julia where their semantics are modified when they take a function as the first argument. This is no different from all of those cases. first(f, itr) seems quite natural to me when you compare it to findfirst(f, A), any(f, itr), all(f, itr), count(f, itr), minimum(f, itr), maximum(f, itr), etc.

The name find is already intentionally not used, because it is more ambiguous than findfirst, findlast, and findall.

Why wouldn't that stand for first(map(f, A))?

Maybe because that's highly inefficient? You would actually want to call f(first(A)) instead, if that's what you are looking for. 🙂

This proposal is analogous to the functions that take a predicate as their first argument, like findfirst, findlast, findall, any, all, and filter. But I can see your point that first doesn't necessarily have the same Boolean-flavor of those functions.

For lack of a better name, firstthat actually kind of makes sense. Or possibly Iterators.findfirst.

[CameronBieganek]

I guess when I think about it more carefully, all of the functions that take an optional function as the first argument (except for things like open and get) have the semantics of foo(f, x) == foo(map(f, x)). I should stop opening issues here, since I'm usually wrong.

[nlw0]

I think it would be nice to have something like that. I think what happens is that Julia is geared towards arrays first, what is generally a good thing. But as a result, functions like these find family were designed to return an index instead of values, and this doesn't generalize well for iterators. There are languages where find gives you a value, not an index, and then you have something like findindex to get indices instead of values.

If Julia's find methods naturally returned values, the examples you gave would be simply working today, but because of the difference in the nature of these data-structures, they're simply breaking these methods. I'd say there's a good case here to figure out how we can have methods that are more generic across different data-structures.

I suggest you keep this open so we can have a conversation. If we recognize there's a desire for find methods that return the value, apart from the key methods already available, what's a good way to implement this? I suggest we can have the same method names, but add an optional values flag. Not sure it's a good idea, it's just a possibility. Making findfirst return a value for iterators and a key for arrays seems like a semantic conflict in my opinion, but with the argument it's fine by me, and we get to use the same method name. A new method for returning a value is another possibility, but I'm not sure what's a good name findvalue seems weird while findindex seems ok.

[nlw0]

By the way, the definition of findfirst is

function findfirst(testf::Function, A)
    for (i, a) in pairs(A)
        testf(a) && return i
    end
    return nothing
end

if it used enumerate instead of pairs it would work. But then it doesn't solve the issue that you want the value, not the index. Note that if that function returned the value it would actually look simpler

function findfirst_nokey(testf::Function, A)
    for a in A
        testf(a) && return a
    end
    return nothing
end

[CameronBieganek]

Ok, here are some of the possible spellings for this new function/feature:

• findfirstvalue
• findfirst(f, itr; value=true)
• firstthat
• Iterators.findfirst

I kind of feel like the best spelling is breaking (v2.0):

Change the name of findfirst to findfirstindex or findfirstkey, and then have findfirst return a value rather than a key or index. And similarly for findlast and findall. Although with findall you would have the thorny question of what kind of object to return---an array or some kind of iterator.

[aplavin]

I guess when I think about it more carefully, all of the functions that take an optional function as the first argument (except for things like open and get) have the semantics of foo(f, x) == foo(map(f, x)).

A notable exception is argmax(f, A)/argmin.
There was a long discussion against their current behavior when these methods were being introduced, with the same consistency argument of foo(f, x) == foo(map(f, x)). But the decision was that this kind of consistency is not a strong requirement for inclusion Julia Base.

[CameronBieganek]

Change the name of findfirst to findfirstindex or findfirstkey, and then have findfirst return a value rather than a key or index. And similarly for findlast and findall. Although with findall you would have the thorny question of what kind of object to return---an array or some kind of iterator.

In an ideal world, I would have something like the following:

• findall returns an iterator of values. If there are no matches, then the iterator is empty.
• findfirst returns a Union{Some{T}, Nothing}, where T is the element type of the input iterator.
• findfirstindex behaves the same as findfirst in Julia 1.x.

...and similarly for findlast/findlastindex.

EDIT: Oh wait, a findall(f, itr) that returns an iterator is the same as Iterators.filter(f, itr).

[CameronBieganek]

A similar discussion has come up on Discourse:

https://discourse.julialang.org/t/does-a-filterfirst-or-filtersingle-function-exist-similar-to-c-single/88690