Boost logo

Boost :

Subject: Re: [boost] [convert] Version in the Vault ready for review.
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-04-01 02:21:34

> From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
> [snip]
> I'll try to clarify.
> 1. Caller wants to get an exception on failure:
> int i(convert<int>::from(str));
> 2. Caller wants to use a default if the conversion fails,
> thus never getting an exception:
> int i(convert<int>::from(str, -1));

Yes. #1&2 are the current interface.

> 3. Caller wants to convert to a target type having no default constructor,
> getting an exception on failure as if there had been no default supplied:
> Foo def(/* something appropriate */);
> convert<Foo>::result r(convert<Foo>::from(str, def));
> Foo f(r.required());

The current interface does it with
Foo foo = convert<Foo>::from(str, def)
>> throw_on_failure/dothrow;
which I personally find easier to read as there is no
convert<>::result-related noise.

> 4. Caller wants no exception, but wants to know whether the conversion
> succeeded:
> convert<int>::result r(convert<int>::from(str));
> if (!r.converted())
> {
> // react to failed conversion
> }

The current interface does it in a similar fashion:

convert<int>::result r = convert<int>::from(str);
if (!r) ... // react to failed conversion

> 5. Caller wants generic code to react to a valid value consistently for
> all types:
> convert<T>::result r(/* call other code */);
> if (r.valid())
> 6. Caller wants generic code to react to a failed conversion consistently
> for all types:
> convert<T>::result r(/* get result somehow */);
> if (!r.converted())

Yes, these #5&6 use-cases are better catered by the interface you advocate.
It might be that I indirectly indicated that I do not feel like encouraging
this interface. I see convert<>::result as a very transient on-the-spot
token to get more information. I do not feel passing it around is a good and
helpful idea. You obviously think differently.

> There are other variations on these ideas, but I hope you start to get the
> idea
> and the need for the interface I've suggested.

Yes, I've got the idea and I see the need for the interface you are
suggesting... if we are to endorse the outlined #5&6 use-cases. In theory
#5&6 cases are valid, in reality I personally and others in my vicinity have
not been using and needing those (otherwise, I'd have no choice but to
implement the functionality already). Therefore, I do not feel like I am
prepared to pay that price... yet.

>> ... If I were to save
>> convert<>::result and pass it to some other function, I'd agree that
>> valid() would be useful
> Why isn't that a valid use case?

Because I do not feel like encouraging spreading the evaluation of the
conversion all over the place (by passing convert::result around). I see
convert as a very direct local operation rather than via some function. It
might be a limited view but it served me well so far.

>> convert<int>::result r1 = convert<int>::from(junk);
>> convert<int>::result r2 = convert<int>::from(junk, -1);
> Can you see, from use case 3 particularly, that your interface is lacking?

#3 is covered by
Foo foo = convert<Foo>::from(str, def) >> throw_on_failure;

> If there are two questions to ask of the result object (valid value and
> successful conversion), then using safe bool as a proxy for successful
> conversion will be confusing.

Agreed. But you might have noticed I am resisting having to ask two
questions. ;-)

> Do you see the value now?
> It indicates whether there is a valid value to extract.
> Code using the result need not know how the result object was created.

I do indeed now understand your view and see your point. And I'd agree with
your proposed interface if I shared your view (namely need to support #5&6)
but in this particular case I don't. I am sorry.

>> Somehow 'required' does not give me a strong enough clue it is about
>> throwing behavior. How about "throw_on_failure". With that I
> If something is required, but not available, what do you expect to happen?
> It could imply a failed assertion, returning a failure code, or throwing
> an exception.
>That required() is called on the result object clearly indicates that the
> is required at the time of the call. One sentence of documentation easily
> reveals that required() throws an exception if the conversion fails,
> so I don't think the verbose "throw_on_failure" is needed. Indeed,
> the latter implies manipulating the conversion process rather than the
> value extraction process, as does "required."

We clearly see it differently as in my book the relevant behavior and
configuration information are centered around conversion operation itself.
Therefore, I see that throw_on_failure or dothrow belong with convert::from
and convert::result is very much on-the-spot helper. You see convert::result
coming to the fore. Therefore, in your book more (and more) weight is given
to convert::result (that I resist).

> ...
> I favor supporting all use cases.

Yes, I understand. It's a noble approach... and expensive. I am a pragmatic.
I want to get as much as I *need* for as little as possible and do not want
to pay for what I do not need. When I do, I'll reconsider. Maybe it is a
short-sighted approach but quite often that 'when' never comes. In this
particular case I just do not see #5&6 coming. If they are, I'll probably
resist them. Not because they do not fit the current convert but because I
do feel it is correct design-wise.

> The interface is neither large nor subtle to me.
> Simple use cases, 1) and 2) above, are straightforward.
> Other use cases are supported.

I feel that the support comes at the expense of convert::result getting
complex... the complexity I am unlikely to ever use.

>> TypeOut const& value() const;
>> operator safebool() const;
> If that were complete, it would indeed be better.

Understood. It seems sufficient for my use-cases. I hear you saying that my
cases are not everyone's cases. Theoretically, I agree. In practice, we all
go by our *own* experiences.

>> I interpret manipulators somewhat more liberally (rather than
>> so firmly associated with std::stream) and do not feel I cannot
>> extend the concept onto convert adding more manipulators in the
>> process.
> I've never seen manipulators used for any other purpose and I think most
> would be surprised at their being used any other way. Thus, it would be
> confusing to think that a dothrow manipulator did not affect the ostream's
> exception throwing behavior but instead affected the convert<>::from()
> call.

I hear you. I truly do. I just feel you are painting the situation somewhat
darker than it really is. I do not believe the "surprise" will be such a big
shock. Boost is full of far bigger surprises. As I indicated we can pass
that throwing information differenty. Like

int i = convert<int>::from(str, -1)(throw_on_failure);
int i = convert<int>::from(str, -1).throw_on_failure();

I found

int i = convert<int>::from(str, -1) >> throw_on_failure;

the least objectionable (to me) as it re-uses already deployed op>>() and
syntax. I.e. the same op>>() and syntax to configure the conversion. I am
not trying to look under convert() and see std::stream there. As a user I
care for conversion and not what *might* be under the hood. After all,
std::stream might *not* be there.


Boost list run by bdawes at, gregod at, cpdaniel at, john at