Re: [boost] [optional_io] InputStreamable refinement

Subject: Re: [boost] [optional_io] InputStreamable refinement
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-03-04 07:55:33

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