Re: [boost] [conversion] ADL and templates

Subject: Re: [boost] [conversion] ADL and templates
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-05-30 18:33:51

Hi Jeff,

Jeffrey Lee Hellrung, Jr.-2 wrote:
> 
> On Mon, May 30, 2011 at 1:51 PM, Vicente BOTET
> <vicente.botet_at_[hidden]>wrote:
> 
>> Hi,
>>
>> I've tried to add a configuration point in Boost.Conversion via
>> overloading
>> and ADL, but while the internal call of the library can find them using a
>> trick that adds a parameter that contains the type of the return type,
>> the
>> user is not able to find them without using the same this trick, but this
>> is
>> too dark to be natural for user code.
>>
>> Next follows a simplified code of the problem. The following
>>
>> namespace N {
>> struct S{};
>>
>> template (*typename T*)
>> T fct1(S const& s) { return T(s); }
>> template (*typename T*)
>> void fct2(T &t, S const& s) { t=s; }
>> }
>>
>> void test ()
>> {
>> N::S s1;
>> N::S s2;
>> fct2(s2, s1);
>> s2=fct1(*N::S*)(s1); // (1)
>> }
>>
>> Results in a compile error in (1)
>>
>> error: ‘fct1’ was not declared in this scope
>>
>> Is it standard behavior that fct1 can not be found by ADL?
>>
>> Thanks,
>> Vicente
>>
>> P.S. Please replace (* and *) by angle brackets.
>>
> 
> AFAIK, this is standard behavior.  Explicitly providing template
> parameters
> to a function call (as well as namespace qualification and putting the
> function name in parentheses) disables ADL. 
> 
> 

Thanks for the information.

> I don't think you can provide
> an extension framework for Boost.Conversion without the result type
> appearing somewhere in the customization function's function parameters.
> 
> I don't really view that as any "darker" than, say, using Boost.EnableIf,
> or
> any of a number of other TMP hacks...they are all constrained from a
> (perhaps) more ideal syntax and form by the constraints of the language.
> 
> 

There is something that is troubling me on the fact that the developer will
customize the conversion function using overload and ADL, but that the user
could not take advantage in a simple way of this overloading. Taking in
account that Boost.Conversion needs already a customization point to take
care of conversion of types in the standard library (using partial
specialization) the addition of the customization point using overload
doesn't make simpler the user code, neither the developers customizing the
class, as it would need to choose between two customization points that
doesn't make any difference. 

If no one find that the additional customization (via overloading) point add
some benefit to the library, I will prefer to remove it (IIRC, Jeff you were
the one that suggested it). This will have the advantage of making the
library quite more simple without limiting his expression power.

Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/conversion-ADL-and-templates-tp3561641p3561841.html
Sent from the Boost - Dev mailing list archive at Nabble.com.