[algorithms, numerics] Replace "exactly" with "at most" in Complexity

[frederick-vs-ja]

Fixes #5636.

Per the discussion in that issue, I think this can be editorial. Although it seems to me that some "exactly" are actually exact.

[jensmaurer]

@jwakely ?

[jwakely]

This doesn't seem like an improvement. Do we want implementations to be allowed to perform fewer than last - first applications for for_each, as an optimization? Or to perform fewer than last - first assignments for std::copy?

If that's allowed, I can make my implementation much faster.

[jwakely]

I agree that for some cases like ranges::shuffle "exactly" isn't helpful, but I don't see why we'd want to remove "exactly" from for_each, copy, etc.

Is the concern that an exception could cause the loop to finish early? Because I don't think we care about that for the Complexity elements.

[frederick-vs-ja]

@jwakely Do you think an LWG would be desired?

As [structure.specifications]/7 says:

Complexity requirements specified in the library clauses are upper bounds, and implementations that provide better complexity guarantees meet the requirements.

It's arguably wrong to say "exactly". But sometimes we exactly want "exactly".

[eisenwave]

For [structure.specifications], it seems like an "unless otherwise specified" would do the job. The point of saying the complexities are upper bounds is that we can then write

Complexity: Linear.

And it's clear that the "linear" is an upper bound. An "exactly" complexity presumably supersedes that.

[tkoeppe]

I'm also open to consider that [structure.specifications] is simply not quite right. It may have started as the plan for how to specify the library, but then it turned out that in specific cases we have more information and can provide exact counts rather than asymptotics, but we never mention that in the description of the element.

It certainly seems unnecessary to say "at most" if we already impy "upper bounds". But moreso: I wonder if we even have a category error and underspecification here: "last - first" is a different kind of thing from "linear". The first is a count, the latter is, presumably, an asymptotic statement. It's not clear that we can even apply the notion of "upper bound" across both; at the very least that would mean very different things: an upper bound on a count is about numbers, but an upper bound on asymptotics would be about the growth (e.g. "upper bound: linear" would allow for "actually logarithmic", but not "actually quadratic").

But [structure.specifications] doesn't say what it means by "complexity", so I don't know how and whether we should change the concrete descriptions we have. I think this should be an LWG issue.