CODEWITHSUNDEEP
c++
Michael Unknown
Michael Unknown

Reputation: 51

Why is there no std::find_not in the STL?

I'm just wondering why there is no std::find_not (taking a value and not a lambda - which is different from std::find_if_not) in the STL. Boost has it for the exact reason I think it should exist:

The existing find variants are: find(), find_if(), and find_if_not(). It seems natural to also have find_not(), for the very reason that we have find_if_not() -- to avoid having to write a lambda to wrap the negation of the find condition.

Is it just a matter of 'nobody proposed it yet' or is there something else?

- mike

Upvotes: 2

Views: 343

Answers (1)

parktomatomi
parktomatomi

Reputation: 4089

This appears to be the proposal for find_if_not:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2569.pdf

It includes this justification:

Just as copy_if is the inverse of remove_copy_if, find_if_not is the inverse of find_if: it returns an iterator pointing to the first element that fails to satisfy a predicate p. It's worth adding for the same reason.

copy_if is proposed in the same document. It includes this:

It is formally redundant [...], but it's worth adding anyways. First, C++ isn't really a functional language and transforming a predicate into its negation is sometimes awkward. Second, the workaround of using double negatives is not unconfusing

So my best guess without asking the author is "both copy_if and find_if_not were added as a convenience to make negative predicates easier. Since find is value-based and the author appears at least a bit reluctant to add redundant versions of algorithms, find_not wasn't considered."

Upvotes: 2

Related Questions