* non-member functions are required if defaults are to be provided for the optional requirements. * There are some non-members that can't be written as overloaded non-member operators but can named free functions (sorry I forget which ones, but I remember seeing one or two along the way). * explicit conversions aren't well supported at present. * Compiler bug workaround (older GCC versions), there's a note at the requirements section: "The non-member functions are all named with an "eval_" prefix to avoid conflicts with template classes of the same name - in point of fact this naming convention shouldn't be necessary, but rather works around some compiler bugs. "
One alternative to using a collection of free functions and metafunctions to extend an interface for a given type is to first mediate this customization via a traits class with static member functions and nested typedefs and metafunctions. Indeed, the default implementation of the traits class would just use the (perhaps overridden) free functions. John: Have you considered this extra level of indirection, or do you have any comments on this?
No, but from a purely practical point of view, I believe the free function approach is easier for both the lib developer and a backend developer - overloading free functions is easy to do and the overload resolution rules well understood I believe. In addition if someone wants to experiment with modifying an existing backend, then extending it's functionality by providing additional function overloads is simple, and requires no modification to the original header. John.