On Wed, Dec 4, 2019, 8:43 AM Marc Mutz via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

I've been telling everyone who (didn't) want to know that std::for_each
is only ever useful for its (very recent) parallelisation capabilities.
That's because for_each is devoid of semantics. What does the thing do?
Does it follow SGI STL rules and just inspects the elements in turn, or
does it take advantage of the leeway that
http://eel.is/c++draft/alg.foreach#2  gave and actually applies an
action to the element? For_each, after all, is still officially a
"non-modifying sequence algorithm", and it's odd that it should be able
to modify elements.

I've also been telling everyone who (didn't) want to know that they can
just write their own inplace_transform, which behaves in all respects
like std::for_each, except for the name.

We can't roll back on http://eel.is/c++draft/alg.foreach#2, but by
providing inplace_transform, we can at least prepare for a future
algorithm vocabulary in which for_each can again no longer modify the


Just my opinion but I'd say that any algorithm extensions suhould build on top of ranges (composibility) and that current algorithms should be left as they are.

As for your suggestion I'm almost certain that ranges already have this capability.