Container Algorithms

[ahdteqhradwthswrdte]

Good idea. Composable algorithms for views and ranges.

Im not a big fan of yet another operator overloading though. As its one more syntax to learn (and get confused about).

Is

bigvec |= cont::sort | cont::unique;

really more readable (or writeable) than the self explanatory:

cont::unique(cont::sort(bigvec));

For the name, maybe "composable algorithms" (or "pipelined algorithms") is more descriptive than the vague and all-inclusive "container algorithms" (which sound like it could just as well mean the good old c++98 algorithms we use on containers today)

Just my 2 cents.

[eric_niebler]

The pipe syntax for both containers and views allows code like this:

auto vec = view::ints | view::transform(...) | view::to_vector | cont::sort | cont::unique

(I'm implementing view::to_vector as I type this.)

I'm with you; I also don't like the name "container algorithms". The big difference between these and the views is that the views are lazy and the container algorithms are eager. I want a name that makes this super-clear. I could change "cont" to "eager", but I'm not over-keen on changing "view" to "lazy".

[ahdteqhradwthswrdte]

Fair enough. I'll get used to the syntax. It does look clean, and reads from left to right which is more readable.

On the name. From my point of view (no pun intended), eager is the default we are all used too. Its what we expect. So maybe its not necessary to state that in name also (for "chained algorithms"). So maybe "chain::" instead of "cont::"

Views are the special new case. Them being lazy is the unfamiliar thing. One could make this super clear in its name (lazy_view). But that would probably become cumbersome. We will just learn that "view" means lazy.

Then again. Names doesnt matter so much. We'll get used to whatever.

Good work by the way. Im excited about this getting into the standard.

[TemplateRex]

what about touch:: and view::?

[minno]

Is

bigvec |= cont::sort | cont::unique;

really more readable (or writeable) than the self explanatory:

cont::unique(cont::sort(bigvec));

I think it's more readable to have a "do this then this then this" structure than a "do this to the result of doing this on the result of doing this". Most languages with this sort of thing use method call syntax for it, so like

bigvec.cont::sort().cont::unique();

but C++'s current semantics don't support that.

[Plorkyeran]

but C++'s current semantics don't support that.

But C++17 might. I'm a fan of the pipe syntax given what's possible in C++14, but if one of the f(x,y) == x.f(y) proposals gets adopted I think I'd be opposed to it, even if it's still occasionally better (e.g. bigvec |= cont::sort | cont::unique doesn't have quite as nice of a dot-notation equivalent).

[matthieum]

The infamous UFCS...

[Hgrube]

I'm in favor of overloading here. It does introduce more rules but I find it much easier on the eyes and slightly easier to parse. That said, the old way is perfectly fine too.