--Michael Fawcett
Boost.Typeof. Boost.Units also handles this gracefully, but I'm not sure how they ended up solving it. Regardless, this is not something the end-user cares how it works, just that it works. It's doable by the library writer, so should be done. ... This type of conversion is handled automatically by the compiler in much simpler expressions:
First off, relying on auto casting is a great way to write template code that only works when the template parameters are built-in types and doesn't even compile when user defined data types are used instead. Moreover, compiler always auto-casts built-in to user defined regardless of what your intention, and believe me, the user does care. The compiler doesn't always do the right thing by default. The rationale that something is possible, therefore it should be done is no rationale at all. Heterogeneous coordinates in the interfaces and internals of algorithms is incompatible with runtime accessors to coordinates and high order constructs. I don't see any value in carrying the individual coordinate data types through the interface into the algorithms. Why not cast them up front in the user-provided accessor functions and let the user who knows and cares what casting they want to get control that. Having one coordinate data type within the algorithms *does* make the implementation of those algorithms simpler and simpler is usually something worth pursuing. Luke