RE: [boost] Re: Proposal for lexical_cast/lexical_convert

From: Bjorn Karlsson (bjorn.karlsson_at_[hidden])
Date: 2002-01-26 09:34:55

> From: Fernando Cacciola [mailto:fcacciola_at_[hidden]]
> 
> I though about this. Perhaps I didn't understand the intended 
> usage for
> this.
> Is it 'just' to avoid exceptions to be thrown in case of 
> error?, or is it
> intended to be used in
> contexts when failure isn't critical and you can ignore it, 
> in which case a
> default Target() is ok as long as a boolean flag is also returned
> I figured that the usefulness resided in the second case, not 
> the first.
> 
> IOWs, I figured that the idea was to have a conversion that 
> always returns
> something, but signaling if it is what was expected.
> Had I misunderstood the idea?
> If the conversion is supposed to return 'nothing' in case of 
> error, then the
> original interface is better.
> If the conversion is supposed to return something, whether 
> the expected
> thing or not, I recommend my interface.
> 

The thing is, if the operation fails, there's no guarantee of the usefulness
of what's returned.

The intent is 0) no exceptions thrown, 1) client selects what consitutes an
error and 2) looks *almost* like lexical_cast.
Rationale:

0) Exceptions aren't always possible to use, either by convention or by lack
of exception support.
1) If a conversion isn't an error, exception handling is not only
unnecessary, it also makes the code less clear.
2) lexical_cast is elegant, functional, useful and well-proven, so
lexical_convert should be similar.

This intent is also achieved in your proposed signature, but IMHO optional
return codes are invitations to poor programming practice. By returning the
result of the operation the user still has the possibility to discard the
return value, but at least they'll know they're pushing their luck :-) (or
clarifying that the operation cannot fail, but that argument holds equally
well for both signatures). 

Does that make sense?

Bjorn