Getting around the non-virtuality of templates

[Simen Kjærås]

On Mon, 26 Mar 2012 00:36:08 +0200, Stewart Gordon <smjg_1998 at yahoo.com>  
wrote:

> I'm coming up against some interesting challenges while porting stuff in  
> my utility library to D2.
>
> Firstly, D2 uses opBinary and opOpAssign, rather than the  
> operator-specific op* and op*Assign.  While the latter still work, they  
> aren't mentioned in the current D2 docs. Which would imply that they're  
> on the way out; however, there's no mention at
> https://github.com/D-Programming-Language/d-programming-language.org/blob/master/deprecate.dd
>
> (See also
> http://d.puremagic.com/issues/show_bug.cgi?id=7779 )
>
> Still, it seems clear that opBinary/opOpAssign is the D2 way of doing  
> it.  But it has the drawback that, because it's a template, it isn't  
> virtual.  One way about it is to keep the D1-style op functions and make  
> opUnary/opBinary/opOpAssign call these.  But is there a better way?
>
> The other isn't a D2-specific issue, though D2 increases the  
> significance of it.  I have a method with the signature
>
>      Set opAnd(bool delegate(Element) dg)
>
> I would like to enable a user of the library to pass in a delegate whose  
> parameter is any type to which Element is implicitly convertible.  This  
> could be the same type as Element with the top-level constancy changed  
> (probably the main use case), or a type that is distinct beyond the  
> constancy level.  Turning it into a template
>
>      Set opAnd(E)(bool delegate(E) dg)
>
> would address this, but prevent overriding with the appropriate code for  
> each set implementation.
>
> Who else has been faced with this problem?  Have you found a good way of  
> dealing with it?
>
> Stewart.

I believe the officially vetted answer is to have the templated calls
forward to virtual functions. Of course, if you need to do something  
specific
before handing it there, you're out of luck.