Some corrections to findn

[fredrikekre]

Fixes this oversight from #23812

julia> findn(rand(2))
┌ Warning: In the future `find(A)` will only work on boolean collections. Use `find(x->x!=0, A)` instead.
│   caller = findn(::Array{Float64,1}) at array.jl:1803
└ @ Base array.jl:1803
2-element Array{Int64,1}:
 1
 2

and adjust the docs for findn (fix #25343).

Two other things I noticed:

• It is a bit incosistent that findn return a tuple for all cases except for vectors. Should we also apply

diff --git a/base/array.jl b/base/array.jl
index d482e18..e1a8ce4 100644
--- a/base/array.jl
+++ b/base/array.jl
@@ -1800,7 +1800,7 @@ end
 find(x::Bool) = x ? [1] : Vector{Int}()
 find(testf::Function, x::Number) = !testf(x) ? Vector{Int}() : [1]
 
-findn(A::AbstractVector) = find(x -> x != 0, A)
+findn(A::AbstractVector) = (find(x -> x != 0, A), )
 
 """
     findn(A)

• Are the methods here in base/array.jl for vectors and matrices needed, or should we simply remove them in favor of

  julia/base/multidimensional.jl

  Lines 692 to 705 in a70504f

  	@generated function findn(A::AbstractArray{T,N}) where {T,N}
  	quote
  	nnzA = count(_countnz, A)
  	@nexprs $N d->(I_d = Vector{Int}(uninitialized, nnzA))
  	k = 1
  	@nloops $N i A begin
  	@inbounds if (@nref $N A i) != zero(T)
  	@nexprs $N d->(I_d[k] = i_d)
  	k += 1
  	end
  	end
  	@ntuple $N I
  	end
  	end

  (which for some simple test cases seems to be more efficient.)

[andreasnoack]

I think the special cases for Vector and Matrix should be deleted.

[fredrikekre]

I think the special cases for Vector and Matrix should be deleted.

Alright, that will also have the result that findn(::AbstractVector) return a 1-tuple, so takes care of both points then I suppose.

[nalimilan]

I'm fine with the proposed changes, but these functions should probably be removed (see #24910). Maybe hold off the PR until we have made a decision about it?

[andreasnoack]

Aren't these fixes separate from the renaming decision? I don't see how merging this would interfere with the renaming/removal.

[nalimilan]

No, it wouldn't interfere, but it's not really useful to change a function just before deprecating it? Not a big deal either way.