On Wed, Dec 4, 2019, 8:43 AM Marc Mutz via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> 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
> sequence.
>
> Thoughts?
>

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.

Regards,
Domen

>