Hi Ilya,
Fernando Cacciola wrote:
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 think so. (We have Boost.Serialization for that)
But I had always believe the current semantics were precisely to support Boost.Serialization... Aparently I've been wrong all along... Since I never used it I never became familar with it.
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.
How are you using operator>> with optional<T>? I can't imagine any common use case other than lexical_cast.
Simply not using Boost.Serialization but other stuff that nevertheless relies on IO operators to do a closed roundtrip conversion.
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).
Btw, the magic space and '--' string is not documented.
Hmmm, that really doesn't look right ;)
Why isn't this enough practically speaking rather than theoretically?
The current semantics is useless for me.
OK. Use case counted :) Best -- Fernando Cacciola SciSoft Consulting http://www.scisoft-consulting.com