IIUC you have this using `ranges` (which itself needs concepts as implemented). With it you can even do :

    for (int i : ints | std::views::filter(even) | std::views::transform(square)) {
        std::cout << i << ' ';
    }

notice the `for (int i:ints)` and the pipes filters.

EDIT: more specifically, you can use sort on a range now (source : https://cppreference.com):

    ranges::sort(s);

The same functionality has been in boost [0] for quite a while. So, if you can't see the ugly iterators anymore, but have an outdated compiler, this is an option.

[0] https://www.boost.org/doc/libs/1_72_0/libs/range/doc/html/in...

Wow, that pipe syntax is quite nice!

Documentation here: https://en.cppreference.com/w/cpp/ranges.

They are called "range adaptors" (weird naming IMHO).

They take a range and adapt it into a view, hence the name.

I wish they had just added the overloads to the std:: namespace though - breaking a few obscure cases would have been worth that.

> breaking a few obscure cases would have been worth that

The committee is very reluctant to break old code. That's one of the reasons the language as documented is so large.

That being said it's not clear to me what would have broken by putting sort(x) into std:: as you recommend.

It’s literally a 3-line utility if you want that:

  template<typename T> void sort(T& t) {
    std::sort(std::begin(t), std::end(t));
  }

Sure. But this is the kind of thing that you would use if it were in the standard headers, but maybe not create (or modify, if it already exists) a work_around_cxx_deficiencies.h in the project and make sure it's included everywhere. Or maybe it's already included in some misc_utils.h in the project but is not easily discoverable, since such "misc utils" headers are always a grab-bag of random unrelated stuff. Whatever the reason, in the C++ projects I worked on we always ended up using the iterator version. We certainly would have used the non-iterator version if it had been available from the standard headers.

In the ideal world ranges would have been in the original standard, but there were two issues.

First, at the time the language did not have enough forwarding capabilities, so you would have needed a lot of overloads to handle const and non const containers.

Second getting anything approved in committee is a huge effort so often proposals are stripped to the bare minimum; in particular the STL was already huge and Stepanov tried to include only what he thought were the fundamental components.

The new ranges have been in development for almost 10 years (arguably they suffered a bit of mission creep), so it is not just a matter of adding range overloads for functions.

I wasn't talking about ranges, I was talking about the grandparent's three-line wrapper function.

well, first of all that wrapper uses std::being/std::end which wasn't available in c++98, second std::sort is "easy" as it is mutating and it doesn't return anything. For other algorithms you want to return ranges (For composability) and things get more complicated.

Regarding the first point: True, but the wrapper could also have been written in terms of foo.begin()/foo.end(), no? Second point: Yes, I would want the easy case solved. Obviously, if an algorithm cannot be wrapped like this, then I'm not asking for the impossible.

No, at least not without a separate overload for C-style arrays. If you don’t care about C arrays then yes, .begin/.end could work.

All generic container manipulating functions use iterations - each of which you’d have to write a utility function for, just to use a couple of times.

What would otherwise be a trivial one liner with something like transform suddenly turns into a 3 line call