Re: [boost] [optional_io] InputStreamable refinement

Subject: Re: [boost] [optional_io] InputStreamable refinement
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-03-03 09:02:39

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