Il 06/03/25 11:23, Robin Savonen Söderholm via Std-Proposals ha scritto:
> A simpler option would be to change the API for the minmax function
> (and perhaps other, similar looking functions) to something where if
> an RValue is detected amongst the arguments, it would return a
> std::pair<T, T> only (or pair<T const, T const>), while if all
> arguments are lvalue references it could keep it's current form (for
> speed or for the need of testing the address of an argument or
> something..)
>
> What would be the best remedy for things like this you think?


This is the kind of things that make C++ a user-hostile language -- a
lifetime trap in such a simple and basic API. I don't think we can
possibly change the shape of these APIs along the lines of you describe,
it'd be an API incompatible change, and lifetime isn't value category.

(For instance: void f(std::pair<const int &, const int &>);
f(std::minmax(a, a-b)); is OK. If you change minmax's return type you're
going to break that code.)


Your best shots are:

1) to use an up-to-date compiler: GCC 14 warns about your construct
https://gcc.godbolt.org/z/Ybb7ce5Y6

2) to ban any usage of std::min/max and roll your own versions (e.g.
my::min/my::max always returning values, my::min_ref/my::max_ref
returning references).


--


Regrettably, the issue you face,
Unfortunately, can't be solved in place.
Since the API's broken, there's no way around,
This problem persists with no fix to be found.


My 2 c,

--
Giuseppe D'Angelo |giuseppe.dangelo_at_[hidden] | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53,http://www.kdab.com
KDAB - Trusted Software Excellence