On Sat, Jul 20, 2013 at 12:13:49PM +0200, JS wrote: > On Saturday, 20 July 2013 at 01:37:13 UTC, Jesse Phillips wrote: > >The relevant blog post: > > > >http://3d.benjamin-thaut.de/?p=94 > > > >What you should understand is template functions are not/can not > >be virtual. They do not exist until they are instantiated. Thus > >you can not require that they be overloaded. > > And this is a compiler limitation? After all, templated functions > are ultimately just normal functions...
Nope. Templated functions don't exist until they're instantiated. Which means the compiler can't know in advance how many instantiations there will be and which ones they are. And given that D supports separate compilation, you *can't* know this (even after linking, there's the possibility that some external dynamic library might instantiate yet another version of the function). There are ways of implementing overloadable templated functions, of course. But they are rather complicated to implement, and incur runtime overhead. > In my case the template parameter is explicitly known and the > overloadable operations being templated isn't my fault. > > I guess I can redirect each templated function to a non-templated > version using the method in benjamin's page but this seems like it > defeats exactly what templates are for... Not really. Having operator overloading implemented as template functions give you more flexibility (albeit at the cost of more code complexity). You could either redirect each operator to an overridable function, or you could do this: class MyClass { auto opBinary(string op)(T t) { // Buahaha, now op is a runtime parameter return opBinaryImpl(op, t); } auto opBinaryImpl(string op, T t) { // which means this method is overridable in // derived classes. ... } } You could also do this only for a certain subset of operators, depending on what granularity you wish to have. I'd write more, but I gotta run. Maybe later. T -- "Hi." "'Lo."