Source:

https://github.com/ericniebler/stl2/blob/3b4b81a961b17528d38589c1dfb0c41b4228c6a8/ext/merge2std2/algorithms.tex

Done and pushed.

Notes and concerns

• The "algorithms" clause still has a lot of troff-era formatting where we start a new line for each non-prose item, such as \tcode{first}. And we have a lot of these. This makes for very long source code. Suggestion: Between the mailings, have me reformat the source code in a no-visual-changes diff.
• Some of the declarations could be made more compact by moving the requires-clause after the template-head on the same line. Is that desirable?
• Declarations are now getting so unwieldly long that it's hard to visually identify the declarator-id. Should we establish a formatting convention that we make it bold or somesuch?
• The algorithms now define a placeholder $E$ to deal with the subvariants of an algorithm (with/without comparator etc.) Very often, this $E$ is an actual C++ expression, so (per our standing rules) should be \tcode{E}. Except for a very few places where we need a parameter and $E(x)$ is used. In the latter cases, \placeholder{E} would be appropriate (similar to the other description meta-functions such as INVOKE). However, using \tcode in one situation and \placeholder in the next seems sub-optimal, too. @zygoloid?
• (not editorial) There are no ExecutionPolicy overloads for the ranges stuff.
• The text uses "shall" with \expects. In the core section, we limit "shall" to diagnosable rules, and \expects is exactly not that. Since we already say in the front matter what \expects means, maybe we can simple use "is" instead of "shall"?

(not editorial) There are no ExecutionPolicy overloads for the ranges stuff.

Yes, because we don't know how to conceptify them yet. It's being actively explored IIRC.

The text uses "shall" with \expects. In the core section, we limit "shall" to diagnosable rules, and \expects is exactly not that.

Current library convention is to use "shall" for requirements on user code. Violation of a library rule is generally UB unless it says "ill-formed" (or \mandates).

"shall" should never be used in an "Expects:". We already say (in [res.on.required]) that "Expects:" specifies a condition, and that violation of that results in UB, so using simply "is" is the correct formulation to describe that condition. (This doesn't affect the conformance of a program or of an implementation, so "shall" is inappropriate.)

The "algorithms" clause still has a lot of troff-era formatting'

Filed #2509 for that.

Some of the declarations could be made more compact by moving the requires-clause after the template-head on the same line.

Filed #2510 for that.

Declarations are now getting so unwieldly long that it's hard to visually identify the declarator-id. Should we establish a formatting convention that we make it bold or somesuch?

Can you open a bug with an example of a case you find particularly bad?

The algorithms now define a placeholder $E$ to deal with the subvariants of an algorithm [...]

Filed #2511 for that.

The text uses "shall" with \expects.

Fixed on motions branch.