Return removed element count in erase and erase_if

[mkurdej]

Disclaimer: if it's not the place to post this type of suggestions, please redirect me to the correct one.

In my opinion, erase and erase_if algorithms added by this TS should return the number of removed elements instead of void.
For instance, std::list::remove and std::list::remove_if (https://en.cppreference.com/w/cpp/container/list/remove) return this count since C++20.

I may be mistaken, but I see no substantial overhead to returnig removed count in erase and erase_if.

For lists and forward_lists, just return c.remove_if(pred); is enough.
For maps, storing old size before the removal, and returning .size() - old_size would be enough.
For vectors and deques, the overhead is minimal and consists in calling std::distance with the iterator resulting from the call to std::remove_if before calling c.erase(...).

I.e. for vectors and deques, it would look like:

template <typename Container, typename Pred>
std::size_t erase_remove_if(Container & c, Pred pred)
{
    const auto last          = std::end(c);
    auto new_last            = std::remove_if(std::begin(c), last, pred);
    const auto removed_count = std::distance(new_last, last);
    c.erase(new_last, last);
    return removed_count;
}

and for node-based containers:

template <typename Container, typename Pred>
std::size_t erase_nodes_if(Container & c, Pred pred)
{
    const std::size_t old_size = std::size(c);

    auto it         = c.begin();
    const auto last = c.end();
    while (it != last)
    {
        if (pred(*it))
        {
            it = c.erase(it);
            assert(last == c.end());
        }
        else
        {
            ++it;
        }
    }

    return old_size - std::size(c);
}

[tkoeppe]

This is indeed not the right place for this. This repository is merely the editorial tool for the TS, and issues here can at most be about editorial matters (whitespace, spelling, unclear presentation).

If you would like to modify the normative content of the TS, you should submit a proposal or a defect report to WG21. (What you propose seems like a design change, though, and not a defect, so a proper proposal, no matter how short, would seem in order.) See https://isocpp.org/std/submit-issue.

(This shouldn't be terribly hard to do, and you can perhaps find a regular committee member to help you champion such a proposal if you can't attend in person.)

[jwakely]

This is not the right place. Only editorial issues in the TS should be reported here. Technical changes to the content need to be proposed to the C++ committee, see:
https://isocpp.org/std/submit-a-proposal
https://isocpp.org/std/submit-issue

I've already raised this issue and there's a proposal to fix it:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1115r0.pdf

[tkoeppe]

More context: http://wg21.link/p1209 was adopted in San Diego and caused the erasure functions to become part of the International Standard. So it might be worth fixing it only there and leave the TS alone. If the TS ends up getting rebased on C++20, all this would be moot.

[jwakely]

Oh yes, I forgot to mention that the P1115 proposal is to fix the versions in C++20. Fixing the versions in the TS is pointless if they're not going to be in the next revision of the TS.

[mkurdej]

OK, thank you all!