Getting around the non-virtuality of templates

James Miller james at aatch.net
Sun Mar 25 15:54:53 PDT 2012


On 26 March 2012 11:36, 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.

Non-virtuality of templates is a general problem at the moment.

The issues seem to be around how to handle inheritance of template
arguments, and how to dispatch the functions based on a combination of
template arguments and class hierarchy. This is a hard problem with no
obvious answer.

in terms of trying to work around it, perhaps compile-time reflection
could help, I haven't encountered this before, but that's where I
would start.

--
James Miller


More information about the Digitalmars-d mailing list