On Wed, Aug 31, 2011 at 5:45 PM, Gordon Woodhull <gordon@woodhull.com> wrote:
On Aug 31, 2011, at 5:11 PM, Emil Dotchevski wrote:
On Wed, Aug 31, 2011 at 1:13 PM, Gordon Woodhull <gordon@woodhull.com> 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:
conversion::convert_to<Target>(source); versus 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. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode