Because findfirst can output a boolean a notthing or an iterator and in this later case, an 0:-1 when it finds nothing. See this example julia> first(findfirst(fieldnames(GMT.GMTgrid), :z)) ┌ Warning: `findfirst(A, v)` is deprecated, use `findfirst(equalto(v), A)` instead. │ caller = top-level s…

I was used to having it returned 0 and then managing the case. A bit taken by the decision to change this in 0.7.

Why would you ever want to call first on a know scalar? And no it’s not dangerous at all. You’ve demonstrated how useful it is to catch user error.

[image] yuyichao: You’ve demonstrated how useful it is to catch user error. No, what I have demonstrated is how EASY is to fall in non-user error. And I called first() so that I can still do a test if output != 0, which is now also more or less useless because of the nothing

[image] Nosferican: I was used to having it returned 0 and then managing the case. A bit taken by the decision to change this in 0.7. It is completely valid for an AbstractArray to have 0 as a valid index. Then what do you do?

[image] joa-quim: can still do a test if output != 0 That is the user error. Why do you want to do such a useless test?

I wasn’t aware AbstractArray supported non \mathbb{N} numbers. I believed it was only possible to index arrays from 1:size(obj, dim). If that is the case, I don’t think 0 was a good previous behavior. Wouldn’t suggest negative index since that might represent (end - index) in future versions. In tha…

[image] yuyichao: Why do you want to do such a useless test? julia> findfirst(“abcd”,“ef”) == 0 false julia> first(findfirst(“abcd”,“ef”)) == 0 true Though I see that I can use isempty() for this case. But not for isempty(nothing) ERROR: MethodError: no method matching start(::Nothing) C…

For a bit of additional texture on the use cases enabled by more flexible indexing I recommend having a look through the JuliaArrays org: https://github.com/JuliaArrays . Two particularly good examples of nontraditional but highly useful indexing are AxisArrays.jl and OffsetArrays.jl .

[image] joa-quim: findfirst(“abcd”,“ef”) That’s not even the same method. It’s not searching for an element in a collection at all so why do you expect it to have exactly the same behavior as searching an array?

I don’t know much about the findfirst usecase for strings as I very rarely do string processing but concerning the element in a collection method, I find the new behavior much better. Returning 0 is not very principled and could lead to issues (for example, if I’m using OffsetArrays, did I find 0 or…

The new output of findfirst is dangerous

General Usage

Topic		Replies	Views
Suggestion for more general/performant sentinel for find* functions Internals & Design	17	1731	January 29, 2018
Findfirst for Dicts with `nothing` keys General Usage	33	3656	March 4, 2018
New findfirst behaviour - type unstable or no? General Usage	5	1235	March 1, 2018
"Simpler" findfirst/firstall methods? Internals & Design	16	973	March 1, 2021
Performance of findfirst in 0.7 Performance	10	1619	April 4, 2018

The new output of findfirst is dangerous

Related topics