Re: [boost] [optional_io] InputStreamable refinement

Subject: Re: [boost] [optional_io] InputStreamable refinement
From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2009-02-25 09:21:45

Andrew wrote:
> ...
> Since it's semantically valid to have an un-initialized optional type,
> I think failure to extract something off a stream should return an empty
> optional type _without_ setting the failbit on the stream.

Andrew,
sorry for the late reply.

optional<T> is about initialized versus uninitialized value, it has nothing
to do with stream's state. IMO, the failbit should be set.

My vision of optional<T> streaming is based on this quote from documentation:

"optional<T> intends to formalize the notion of initialization (or lack of it)
allowing a program to test whether an object has been initialized and stating
that access to the value of an uninitialized object is undefined behavior."

Thus,
 - after a successful read the stream is in a good state and the value is 
initialized,
 - after read failure, the failbit bit is set and the value is uninitialized,
 - printing of initialized optional<T> value produces the same result as 
printing T value,
 - printing of uninitialized value sets the failbit.

> However there is still one problem, and this brings us back to
> lexical_cast. Consider this example:
>      int an_invalid_uint = -1;
>      unsigned i = lexical_cast<optional<unsigned> >  
> (an_invalid_uint).get_value_or (0);
> ...
> So is there any interest in this sort of refinement of optional's  
> InputStreamable implementation or lexical_cast?

My streaming proposal makes lexical_cast < optional<T> >(v) equivalent to
lexical_cast<T>(v) because it would never return uninitialized value.
I can use it as a good excuse for implementing no-throw version of
lexical_cast < optional<T> >(v) ;-)

Alex