ADL

Guillaume Boucher via Digitalmars-d digitalmars-d at puremagic.com
Tue Sep 6 02:01:27 PDT 2016


On Monday, 5 September 2016 at 23:50:33 UTC, Timon Gehr wrote:
> One hacky way is to provide a mixin template to create a 
> wrapper type within each module that needs it, with 
> std.typecons.Proxy. Proxy picks up UFCS functions in addition 
> to member functions and turns them into member functions. But 
> this leads to a lot of template bloat, because callers that 
> share the same added UFCS functions don't actually share the 
> instantiation. Also, it only works one level deep and 
> automatically generated Wrapper types are generally prone to be 
> somewhat brittle.

I don't think cloning a type just to add functionality can 
possibly be the right way.

A C++-style of customizing behavior is using traits. Those traits 
would be a compile time argument to the algorithm function.  
Instead of arg.addone() one would use trait.addone(arg).  It is 
not hard to write a proxy that merges trait and arg into one 
entity, but this should to be done from the callee.

The default trait would be type.addone_trait if it exists, or 
else some default trait that uses all available functions and 
member function from the module of the type.  In most of the 
cases this is enough, but it enables adding traits to existing 
types and also different implementations of the same traits.

This gets really bloaty in C++, and that's why usually ADL is 
preferred, but D has the capability to reduce the overhead to a 
minimum.

It doesn't quite make it possible to separate the implementation 
of types, algorithms and traits (UFCS) into different modules 
such that they don't know each other.  Either the user has to 
specify the trait each call or either the type's module or the 
algorithm's module has to import the traits.

What I call traits is very similar to type classes in other 
languages where (among other features) the traits are 
automatically being attached to the type.  (Type classes are also 
what C++ concepts originally wanted to be.)


More information about the Digitalmars-d mailing list