Function overloading concern

[Sean Kelly]

Carlos Santander wrote:
> Sean Kelly escribió:
>>
>> By the way, the more complex C++ examples don't work in D anyway, 
>> because D is module-based.  For example, it's more likely func would 
>> be defined in a third module like so:
>>
>> Module C:
>>
>>     module c;
>>     import b; // let's say b is the default implementation
>>
>>     template func( T )
>>     {
>>         void func( inout T t1, inout T t2 )
>>         {
>>             swap( t1, t2 );
>>         }
>>     }
>>
>> Main:
>>
>>     import a;
>>     import c;
>>
>>     void main()
>>     {
>>         int i = 1, j = 2;
>>         func( s, t );
>>     }
>>
>> However, this doesn't work in D even without overloading.  So perhaps 
>> it's not much of an issue here anyway.
>>
>>
>> Sean
> 
> This one, I don't understand. I don't have DMD to try the code, but I 
> think the call sequence would be something like:
> 
> main -> c.func -> b.swap
> 
> The main module imports a, but it's never used.

The above example doesn't really make sense in D but it's quite common 
in C++, whose current import mechanism is little more than a structured 
copy/paste during preprocessing (recall that module A defines the 
overload that Main wants to be used by module C).  But this is 
semantically meaningless in D, which was my only point--that perhaps C++ 
overload resolution really isn't necessary in D after all.

> The only thing that I can think of is that you want c.func to use a.swap 
> because it was imported in main, but it doesn't make much sense (for me, 
> anyway) because c never knew about a. I don't know if C++ allows that, 
> but I would say it's not a very good design. There should be another 
> way. IMHO.

It's not a good design, but the C/C++ people are stuck with it :-) 
There's been a recent push to adopt a module import scheme for C++, but 
I think the huge mass of legacy code like the above will make the scheme 
very difficult to use.


Sean