On 06/03/2025 18.56, Howard Hinnant via Std-Proposals wrote:
> On Mar 6, 2025, at 6:50 AM, Jens Maurer via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
>> On 06/03/2025 12.18, Jonathan Wakely via Std-Proposals wrote:
>>> See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2199.html <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2199.html> which was rejected long ago.
>>
>> Maybe it's time to reconsider, after 15+ years.
>>
>> If we can't change the existing interface, we could at least
>> offer replacements under a different name. Unfortunately,
>> std::ranges::min/max is already taken, with a proliferation
>> of the existing interface.
> I was in the room when it was rejected. The reason it was rejected was not because the proposed behavior was not desired. It was rejected because the *implementation* was considered too complicated. The committee found the *implementaiton* to be complicated to the point of embarrassment to the langauge.
What? Since when is the committee bothered with implementation complexity
of a fairly simple library feature?
If it's complex, it's not simple.
But yeah, WG21 in modern times cares little for implementation complexity (witness all of Ranges; std::hive; gestures broadly in the direction of Unicode).
And I agree that the implementation could at least
look smaller in a new revision. In fact a large part of it is basically reimplementing C++20
`cmp_less` but with the arithmetic return value instead of just a `bool`.
We should have this ASAP, with a modern implementation. Any takers?
I'd happily review new wording/implementation, but am not inclined to author.
IIUC, the design intent is that this doesn't change any existing behavior or signatures of min/max/minmax, but merely expands the range of well-formed calls to include a lot of things that are ill-formed today?
auto x = std::minmax(A(), A()); // same old behavior
auto y = std::minmax(A(), B()); // today: ill-formed; tomorrow: shiny new behavior
right?
–Arthur