On May 21, 2004, at 12:17 AM, Stephan T. Lavavej wrote:

About two weeks ago I pointed out a fairly serious factual error in the Boost Lambda documentation, described here:

Here's your earlier message:

...

[1] Strictly taken, the C++ standard defines for_each as a non-modifying sequence operation, and the function object passed to for_each should not modify its argument. The requirements for the arguments of for_each are unnecessary strict, since as long as the iterators are mutable, for_each accepts a function object that can have side-effects on their argument. Nevertheless, it is straightforward to provide another function template with the functionality of std::for_each but more fine-grained requirements for its arguments.

This is incorrect, as well as having a typo.

for_each is described as "non-modifying" in the Standard because it does not inherently modify sequences (contrast copy() and friends). However, the functor it takes can mutate its argument.

This footnote must be removed.

I'm reading the standard back and forth and I do not agree with you. I agree with the typo, but not that the footnote is inaccurate, and not that if it is, it is fairly serious. 25.1.(5) If an algorithm’s Effects section says that a value pointed to by any iterator passed as an argument is modified, then that algorithm has an additional type requirement: The type of that argument shall satisfy the requirements of a mutable iterator (24.1). The effects clause of for_each does not say that the value pointed to by any iterator passed as an argument is modified, which leads me to conclude that a conforming implementation is free to implement for_each in a way that does not allow modifications to the values pointed to by the iterators. What do you mean by "inherently mutating sequences"? Does std::replace inherently modidfy sequences? Best, Jaakko