Does C++ standardize the behavior of std::optional under std::min and std::max?

Question

I don't have a very recent compiler installed to get a hint of what the final std::optional semantics are going to be. But in C++14, the following:

#include <experimental/optional>
#include <algorithm>

int main()
{
    using oint = std::experimental::optional<int>;
    int x = std::max(1, 2);
    auto oy = oint{3};
    auto z = std::max(x, oy);
}

does not compile. Now, in the future, I would expect/hope that z would get 3 in this case; and if oy = oint{} then z could get 2.

Is something like what I expected standardized in C++17, or proposed for standardization later? Alternatively, is the undefinability standardized (like it sort of is in C++14)?

Note: The motivation here is possibly implementing something myself, for pre-C++17 code; if something relevant is planned to be standardized I'll try to match that.

I don't see how this is confusing. [`std::max`](http://en.cppreference.com/w/cpp/algorithm/max) expects its two parameters to have the same type. — Justin, Aug 02 '17 at 20:50
[`std::optional`](http://en.cppreference.com/w/cpp/utility/optional/operator_cmp) has comparison operators; you might do `std::max(oint{x}, oy)` — Justin, Aug 02 '17 at 20:51
... or, as a worse alternative, going the roundabout one-off manual way with `std::max(x, oy.value_or(std::numeric_limits::min()));`. — dfrib, Aug 02 '17 at 21:04
I don't see the reason for the down-votes. It's well written, with a MCVE and a mostly definitive answer. — StoryTeller - Unslander Monica, Aug 02 '17 at 21:14
@StoryTeller: It's StackOverflow. People are unfriendly to say the least. — einpoklum, Aug 02 '17 at 21:16
@Justin: I didn't say it was confusing. I just don't know whether there's an exception planned for `std::optional`'s. — einpoklum, Aug 02 '17 at 21:18
Considering Justin's solution I dont see why `std::max` needs an exception for `std::optional`. — Borgleader, Aug 02 '17 at 21:21
Becausr this question does not show any research effort and is written in a way that does not seem helpful to future readers? — cpplearner, Aug 02 '17 at 21:24
@cpplearner - It shows more research effort than 75% of questions on SO. And since when are we penalizing someone for not knowing *where* to look? The voting mechanism is to address quality. And helping future readers is what community editing is for, not to mention *commenting* on the post to let the OP *know how to improve*. — StoryTeller - Unslander Monica, Aug 02 '17 at 21:29
@Borgleader: I didn't try to _argue_ for it, I asked if something like this was planned to be in the standard or not, that's it. I wonder if people downvoted because of this reason... — einpoklum, Aug 02 '17 at 21:30
I'm not saying you did, all I'm saying is I dont see the point of it. Furthermore theres no need for the standard to explicitly "forbid this", and theres no "undefinability", max takes 2 arguments *of the same type* these dont have the same type so theres nothing to say because by the definition of max it's not supposed to work. They *could* make an exception, but again, Justin presented an elegant solution to that and since you're not making a case for why this should be in the standard or why someone may have wanted this in the standard I'm not sure where you're going with this question. — Borgleader, Aug 02 '17 at 21:39
@T.C. That's [catching the `initializer_list` overload](https://wandbox.org/permlink/taEts2coVbc9gcmx), and failing because `oy` isn't callable as a comparator. — Justin, Aug 02 '17 at 21:59
@Justin Bah, `std::max(oy, {x})` then. I want concepts and properly constrained algorithms *now*. — T.C., Aug 02 '17 at 21:59
@T.C. Yes, you can do `std::max(oy, {x})`, but I wouldn't because it is clearer to me to do `std::max(oy, oint{x})`. But that comes down to preference, especially if you don't have the type alias for `oint` to begin with — Justin, Aug 02 '17 at 22:01
@Justin Right, the neat thing about it is not having to repeat the type. — T.C., Aug 02 '17 at 22:01
@Justin: Thank you for your comments. I can see why you would think that's the reasonable thing to expect. My intuition says "if there's no value in the optional it's like a maximum with a single argument". — einpoklum, Aug 02 '17 at 22:14

score 3 · Accepted Answer · answered Aug 02 '17 at 23:08

Is something like what I expected standardized in C++17

No.

, or proposed for standardization later?

There is no such proposal in any of the mailings.

Though of course there's plenty of easy workarounds, so there's little reason for such a proposal:

oy ? std::max(x,*oy) : x;
x < oy ? *oy : x
*std::max(oint(x), oy)
*std::max<oint>(x, oy)
*std::max(oy, {x})
std::max(x, oy.value_or(x))

There's probably others. The first two can't give you a dangling reference, the last four could.

Does C++ standardize the behavior of std::optional under std::min and std::max?

1 Answers1