Hi Luke, I don't think we have addressed exactly the same thing, but something similar. We check geometry types at compile time, indeed using a generic geometry type system. Area calculation, for example, is implemented differently for box (rectangle) than for polygon. So we have two overloads: template <typename B> double area(const B& box) {...} template <typename P> double area(const P& polyon) {...} This alone leads to ambiguities of course. Therefore we use enable_if: template <typename B> double area(const B& box, typename boost::enable_if_c<geometry_type<B>::type == TYPE_BOX>::type* = 0) template <typename P> double area(const P& polyon, typename boost::enable_if_c<geometry_type<P>::type == TYPE_POLYGON>::type* = 0) This works perfectly and distinguishes all geometry types at compile time, as long as the library or the developer provides the meta function geometry_type<T>::type which is currently implemented as an enumeration of TYPE_POINT, etc. Furthermore, you mention: "concept checking boilerplate around bool return type goes here". We've encountered problems with the concept checking on return types. The combination of BCCL and overloads based on SFINAE gives compiler problems here. We therefore use BOOST_CONCEPT_REQUIRES instead of _ASSERT in such cases. (We introduced the geometry type meta function since our preview3, it is planned to be published this month). Regards, Barend Simonson, Lucanus J wrote:
There is a clear need for concept casting in a generic geometry type system <... snipped>