This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 290. Requirements to for_each and its function object

Section: 27.6.5 [alg.foreach] Status: NAD Submitter: Angelika Langer Opened: 2001-01-03 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [alg.foreach].

View all issues with NAD status.

Discussion:

The specification of the for_each algorithm does not have a "Requires" section, which means that there are no restrictions imposed on the function object whatsoever. In essence it means that I can provide any function object with arbitrary side effects and I can still expect a predictable result. In particular I can expect that the function object is applied exactly last - first times, which is promised in the "Complexity" section.

I don't see how any implementation can give such a guarantee without imposing requirements on the function object.

Just as an example: consider a function object that removes elements from the input sequence. In that case, what does the complexity guarantee (applies f exactly last - first times) mean?

One can argue that this is obviously a nonsensical application and a theoretical case, which unfortunately it isn't. I have seen programmers shooting themselves in the foot this way, and they did not understand that there are restrictions even if the description of the algorithm does not say so.

[Lillehammer: This is more general than for_each. We don't want the function object in transform invalidiating iterators either. There should be a note somewhere in clause 17 (17, not 25) saying that user code operating on a range may not invalidate iterators unless otherwise specified. Bill will provide wording.]

[ 2009-07 Frankfurt ]

> Moved to NAD.

> It was felt that the current description is adequate, and that there are limits to what the standard can reasonably say to prohibit perverse uses of the library.

Proposed resolution: