Stephan T. Lavavej [MSFT] <stl@microsoft.com> wrote:
There's a fundamental reason.
#1: When x is "smaller" than y, min(x, y) is required to return x.
#2: When x is "equivalent" to y, min(x, y) is required to return x.
#3: When x is "larger" than y, min(x, y) is required to return y.
For std::less-like predicates, there's a very simple implementation
that achieves this: return y < x ? y : x; and return pred(y, x) ?
y : x; for the generalized implementation.
Now suppose that min() allowed std::less_equal-like predicates.
return pred(y, x) ? y : x; doesn't work for std::less_equal (it
returns y for #2).
Ah, but Vladimir _wants_ it to return y for #2. He wants to use
less_equal specifically for this purpose, trying to take advantage
of an implementation detail. His complaint is about the debugging
feature in MSVC STL implementation whereby less_equal is explicitly
checked for and rejected (well, not specifically less_equal, but
any predicate that violates strict weak ordering requirements).
Basically, his argument is that, instead of mandating that min()
return the smaller of the two elements, the standard should have
just stated that min(x, y, pred) returns (pred(y, x) ? y : x). Then
std::less and std::less_equal would behave the way he wants (but
not necessarily the way that obeys the principle of least
surprise).
implementation details, instead of the required result. Had it done