----- Original Message -----

From: Bjorn Karlsson

To: 'boost@yahoogroups.com'

Sent: Saturday, January 26, 2002 11:34 AM

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

> From: Fernando Cacciola [mailto:fcacciola@gosierra.com]
>
> 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

Could you elaborate how *exactly* "optional return codes are invitations to poor programming practice"?

Your signature returns a bool on one hand, and, on the other hand; fills in -or not- the target.

So the target, as a result, is 100% optional in any signature, even though this fact isn't explicit in the interface.

With your interface, if the user forgets to check if a result has been really returned, this error might not be critical because the value being left in the target variable could be a reasonable default.

The interface I proposed dealt with it returning a default constructed Target() result.

I think both interfaces give optional results, but yours allows a user defined default value to be the 'optional', so in this respect is more flexible.

Notice that the usage of optional<> provides the safest interface: there is no way you can accidentally use a value which wasn't returned by lexical_convert(). optional<> behaves like a NULL pointer if lexical_convert() failed, as soon as you try to dereference it you get an assertion violation.

Fernando Cacciola
Sierra s.r.l.
fcacciola@gosierra.com
www.gosierra.com