template member function confusion

[Stefan]

On Sunday, 8 April 2012 at 20:51:52 UTC, Francois Chabot wrote:
> class Bar
> {
>   Binding[string] Bindings ;
>
>   //cached function
>   void foo( Foo target , const ref Matrix44 val ) { ... }
>   void foo( Foo target , const ref Vec4 val ) { ... }
>   //... more function...
>
>   //convenience interface for non-critical code-paths
>   void foo(T)( string target , const ref T val ) { foo( 
> Bindings[target] , val ) ; }
>
> }
>
> DMD gives me the following:
> Error: Bar.foo(T) conflicts with function Bar.foo at ...
>
> Now, I can easily
> A) Change the name of either one the functions (which yields a 
> slightly less elegant interface)
> B) Not use a template and put string versions of all the foos 
> (which yields ugly code)
> C) Make the binding-based interface a template and implement 
> the functions through specialization (as they are unfortunately 
> different enough to not be templatable). While maintaining the 
> interface and conciseness, it feels like a hack to me.

If you ask me, choose C - that's the most consistent solution. 
It's perfectly OK to have specialized templates. That's not a 
hack, it's a feature ;-)

Regarding the virtualization discussion: You could still use 
method dispatcher pairs, such as

// Specialization
void foo(T: Matrix44)( Foo target , const ref Matrix44 val ) { 
myfoo(target , val); }
void myfoo( Foo target , const ref Matrix44 val ) { /* real 
functionality here */ }
// general "swiss knife"
void foo(T)( string target , const ref T val ) { myfoo(target , 
val); }
void myfoo( Foo target , const ref Variant val ) { /* real 
functionality here */ }

Then the myfoo methods would be overloadable. If you want the 
"total hack", you could wrap the specialization pairs into 
mixins. This way, only the foo wrappers are visible to the human 
user, but the compiler also sees the overloadable, "ordinary" 
methods.

Cheers,
Stefan