Date: Sun, 25 Jun 2023 11:44:42 +0300
On 6/25/23 04:37, Kevin Schmidt via Std-Proposals wrote:
> On 6/25/23 01:32, Andrey Semashev via Std-Proposals wrote:
>
> This means you cannot read an empty optional from the stream.
>
> Indeed, as currently proposed, there's no way to read an empty optional
> from the stream. An approach to handling this could be to introduce a
> keyword or sentinel value which, when read from the stream, sets the
> std::optional to empty.
Such a sentinel would need to have a distinct string representation from
any other value of the type T in optional<T>. With arbitrary T and no
explicit markup for the formatted value of T in the string, I don't
think you will be able to define such a sentinel.
For example, how would you define it for std::optional<std::string>?
> Also, if you introduce an operator>>, it is only natural to introduce an
> operator<< as well.
>
> I agree, but in the initial proposal, I just mainly focused on streaming
> in for simplicity, though I do agree that an operator<< would help make
> the API more symmetric.
I don't think having operator>> and not operator<< would be useful.
> On 6/25/23 01:32, Andrey Semashev via Std-Proposals wrote:
>
> This means you cannot read an empty optional from the stream.
>
> Indeed, as currently proposed, there's no way to read an empty optional
> from the stream. An approach to handling this could be to introduce a
> keyword or sentinel value which, when read from the stream, sets the
> std::optional to empty.
Such a sentinel would need to have a distinct string representation from
any other value of the type T in optional<T>. With arbitrary T and no
explicit markup for the formatted value of T in the string, I don't
think you will be able to define such a sentinel.
For example, how would you define it for std::optional<std::string>?
> Also, if you introduce an operator>>, it is only natural to introduce an
> operator<< as well.
>
> I agree, but in the initial proposal, I just mainly focused on streaming
> in for simplicity, though I do agree that an operator<< would help make
> the API more symmetric.
I don't think having operator>> and not operator<< would be useful.
Received on 2023-06-25 08:45:07