Add callable support for find and rfind Array methods

[SlashScreen]

I have implemented a number of methods for using callables with:

• find (find_custom)
• rfind (rfind_custom)
• count (count_cusom)

I implemented these in a previous PR, but I accidentally deleted it when cleaning up my github, so I am doing it again. Also, I am better at contributing to codebases now, and working with C++.

On the last PR, count_custom could just be reduce, and indeed that's what it uses internally, but I would argue that this is okay, as there is precedent for using simple wrapper methods to avoid confusion with less experienced programmers and work with their intuition (has relies on find, append is an alias for push_back). On the other hand, instead of max_custom and min _custom, you're instructed to use reduce instead, so there is precedence against, too.

Closes godotengine/godot-proposals#6889

[SlashScreen]

Looks like I need to write tests. Also, I think my count_custom implementation using reduce is problematic. I can hand-roll it, or remove it entirely.

[SlashScreen]

Where are tests for sort_custom written?

[SlashScreen]

@AThousandShips resolved. Good catch. Also realized that _count_reduce wouldn't have actually done anything, so I fixed that.

A few remaining questions:

• Where should I put tests for these?
• The CI build keeps failing on linux-mono, for some reason involving the doc tool. I don't totally understand the failure here.
• I briefly implemented a take_while method before realizing that it could be simplified to find_custom + slice. Should I add that back in, along with any more functional programming-style methods? I can see skip (creating a new array made of every nth element of the source) being useful, and there's also things like zip and unzip. Could be out of the scope of the PR, though.

[AThousandShips]

Where should I put tests for these?

Here tests/core/variant/test_array.h

Once you've fixed the callable argument issue we can see what the doc things are

[SlashScreen]

Where should I put tests for these?

Here tests/core/variant/test_array.h

Once you've fixed the callable argument issue we can see what the doc things are

I fixed the const issue. I was going to put the test in there, but I didn't see one for filter, so I wasn't sure if there was a special place I couldn't find. I'll add the tests now.

[AThousandShips]

This should fix CI

[SlashScreen]

I've added the tests, and fixed the bind method. Good catch. Makes sense that that failed.

[SlashScreen]

Sorry, I caught a typo.

[SlashScreen]

Tests run during CI, right?

[SlashScreen]

If I added these changes, would I have to go through the approval process again?...

[KoBeWi]

No.
Also this still needs approval from core team anyway. I implemented similar methods before, so I can tell whether the code is ok, but core team has final saying whether the feature should be added (although it's a formality at this point).

[SlashScreen]

The CI says there's a duplicate declaration of Array? What?

[KoBeWi]

You accidentally pushed some wrong file

[SlashScreen]

oops.

[SlashScreen]

@Nazarwadim done.

[dalexeev]

To me count_custom() makes sense. Of course, reduce() can be used instead, but it is less convenient than a unary predicate. reduce() is a general function, and count_custom() is a common special case, in my opinion.

[SlashScreen]

To me count_custom() makes sense. Of course, reduce() can be used instead, but it is less convenient than a unary predicate. reduce() is a general function, and count_custom() is a common special case, in my opinion.

I agree, but the consensus seemed to be to remove it.

[SlashScreen]

@Nazarwadim @dalexeev done.

[akien-mga]

This seems to have significant demand as there's been already at least 3 PRs attempting to implement this, and the linked proposal is somewhat consensual.

The proposed API seems fine to me. I didn't review implementation details but others did, so I think this is good to go.

[akien-mga]

Thanks!