Hello everybody, I would like to propose the following for the new standard:

Motivation:

Currently, std::optional does not have an operator>> defined, so values cannot be streamed directly into an std::optional. Users have to explicitly extract the value from the stream and assign it to the std::optional using emplace() or operator=(). By adding operator>> overloads, std::optional can support more intuitive streaming input.

Initial Design Proposition:

template <typename T>
std::istream& operator>>(std::istream& is, std::optional<T>& opt) {
    T value;
    if (is >> value) {
        opt.emplace(value);
    } else {
        opt.reset();
    }
    return is;
}

This defines an operator>> that extracts a value of type T from the input stream "is" and assigns it to the std::optional<T> object "opt". If the extraction succeeds, the value is emplace()d into "opt". If it fails, "opt" is reset to an empty state. This is just a basic implementation that can be used without the internals. For the implementation into the standard I would suggest a rewrite using the internals of std::optional to overcome the issue of using one unnecessary stack allocation. I still believe that mentioning this is important though since this code can be used as a premature implementation for now.

The implementation allows code like:

std::optional<int> opt;
std::istringstream("123") >> opt;
// opt is 123

Impact on the Standard:

This change will make std::optional more intuitive to use for streaming input, as values can be extracted directly into an optional without needing to handle the empty case explicitly. It brings std::optional inline with other wrapper types like std::variant that support streaming through operator>> overloads.

The proposed changes are limited to overloads for std::istream and its derived types. Overloads for other stream types can be added separately. The proposed design is limited to a single-argument overload to avoid ambiguity, but additional overloads can be defined if needed.

This change should have limited impact on existing code, as it purely adds additional functionality. The proposed design has been kept simple, but can be extended in the future if needed.

I hope that this fits nicely into the standard, any feedback or improvement suggestions are welcome.

Thanks for your attention,
Kevin