Hi Alexander,
Fernando Cacciola <fernando.cacciola <at> gmail.com> writes:
[skip] That is, the current optional_io.hpp is explicitely not designed to support your use case. Instead, it is designed to support the following use case:
optional<T> in = -value_or_empty-
stream << in ;
optional<T> out ; stream >> out ;
assert( in == out ) ;
How can you guarantee this if not all underlying types guarantees this?
I can't of course, and I wouldn't even try. For instance, your counter-example fails with both the current and your proposed implementation. Or are you saying that, since supporting such a requirement is not entirely possible since in the end is up to T, it isn't worth doing the best optional<T> itself can?
I don't care about lexical_cast here
OK, but you two clearly care for extracting an optional<T> from a stream that was insterted a bare T instead of an optional<T>. The current implementation is just not intended to support that.
my implementation is based on reading Boost.Optional documentation:
I figured. This is once again the now classic dicotomy between optional<T> as a super T or as a singleton container of T. This always raise endless discussions simply because both views are reasonable.
on Boost.Optional.
Was it during review or after?
Long way after the review of Optional, when lots of people started using it.
Do you have a link to this discussion?
Not that I can find real quick. I personally never ever needed to extract an optional<T> where a bare T (instead of an optional<T>) was inserted, so the current semantics just worked for me. So, let me step back a bit... Why do you (Andrew and you Alexander) need this? With the current implementation you can certainly correctly extract the correct output provided the stream was inserted an optional<T>, subject of course to the details of T (as exposed in your counter-example). Why isn't this enough practically speaking rather than theoretically? Best -- Fernando Cacciola SciSoft Consulting http://www.scisoft-consulting.com