Subject: Re: [boost] [conversion] review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2011-08-31 21:15:52
On Wed, Aug 31, 2011 at 5:45 PM, Gordon Woodhull <gordon_at_[hidden]> wrote:
> On Aug 31, 2011, at 5:11 PM, Emil Dotchevski wrote:
>> On Wed, Aug 31, 2011 at 1:13 PM, Gordon Woodhull <gordon_at_[hidden]> wrote:
>>> On Aug 31, 2011, at 3:01 PM, Emil Dotchevski wrote:
>>>> I do agree however that the call syntax should not rely on <>. One
>>>> reason is that it turns off ADL. Another reason is that sometimes an
>>>> implicit conversion to match an existing non-template overload is
>>>> preferable to instantiating a template.
>>> The function overload customization point in Conversion uses a dummy parameter and no <>. convert_to<> is a just a more pleasant wrapper over that. So I think these language features are still available.
>> What makes it more pleasant? Is it more convenient? In what use cases?
> We are talking about a library that emulates overloading static_cast. The wrapper makes it look somewhat like static_cast<>(), whereas if you directly had to use the customization point it would be a mess:
> explicit_convert_to(source, conversion::type_tag<Target>())
Ah. I'm not sure I like the fact that it is modeled after static_cast
but I understand.
> In other words, the ugliness is confined to the definition of conversions and doesn't spill over into their use. But the conversion definitions do get to benefit from ADL... actually I don't see how a conversion library could benefit from implicit conversions of the target type, but I might be missing something.
My point about ADL doesn't apply since the <> syntax is limited only
to the point of the user calling convert_to, that is, as long as
explicit_convert_to still uses ADL and it is not required to be a
template, all is good.
When I mentioned implicit conversions, I meant of the source type.
Assuming the internals of convert_to<> do not require the actual
conversion to be handled by templates, it is possible to define a
small set of non-template overloads to handle a much larger set of
input types that are already part of a carefully designed implicit
conversion framework. If templates were required, the call to
explicit_convert_to could instantiate a template instead of resorting
to implicit conversion. I'm not saying that one is better than the
other, only that both should be supported.
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk