Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-05 07:29:20

Vladimir Batov wrote:
> > Scott McMurray <me22.ca+boost <at> gmail.com> writes:
> >> Gordon Woodhull <gordon <at> woodhull.com> wrote:
> >>
> >> Please read the posts (esp Thomas Heller's and Christopher
> >> Jefferson's) about how implicit conversions break template
> >> functions and auto. They're more than just scary.
> >
> > I completely agree they're not appropriate in the normal
> > path.
>
> I do not want to re-start that sub-thread. Still, I feel that
> that line of 'convert' releasing the Satan with implicit
> conversions to the Target type and to convert<Target>::result
> has been blown out of all proportions.

Implicit conversions can cause many unfortunate behaviors when used in generic code, which Boost fosters, of course.  It is also wise to prevent unintentional misuse when possible.  That is, a good interface will help the user avoid mistakes and implicit conversions can interfere with that.

> The implicit conversion to the Target type was essentially a
> convenience (which we in our project deploy all the time). We
> could remove it as it could be retrieved with value().

That's always the justification for implicit conversions: convenience.  That doesn't mean they don't cause trouble.

> Does the only remaining implicit conversion to such specific
> type convert<>::result still look scary?

It isn't scary.  It is troublesome by introducing ambiguities or mistaken template instantiations.

> In reality, all that was needed to avoid the "break template
> functions and auto" scenario was
>
>     template<class T> foo(T const&);
>     int v = convert<int>from(str);
>     auto v1 = convert<int>from(str).value();
>     foo(v); // correct template resolution
> or
>     template<class T> foo(T const&);
>     foo(convert<int>from(str).value);
>
> Was it too much to ask?

Yes, I think so, though I hadn't noticed it before it was raised during the review.  The problem is that "convert<int>::from(str)" looks like it should provide a number.  Indeed, "convert_cast<int>(str)" must to follow the pattern.  Thus, having to remember to call value() on what looks like shouldn't need it, is frustrating.  Worse, what template error backtraces will result?  Furthermore, the author of foo() might want to help and so might provide an overload for convert<int>::result in order to call value() for its callers ("to improve interoperability").  Repeating that for every foo() would be irksome.

> How many libraries can claim to support an attitude like
> -- I do not want to read the documentation, I want to call
> those functions as I see fit and I expect them to work
> correctly?

That's not how I view it.  Instead, the concern is that the implicit conversions are not required, so avoid them to preclude their troublesome aspects.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer                     using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.