I have completed initial implementation of the operator based syntax I proposed for polygon set operations (Booleans) and hooked up the actual algorithms and data structures to that API. You can see the complete pattern in the sandbox: http://svn.boost.org/trac/boost/browser/sandbox/gtl/gtl The operator&() declaration now looks like this: template <typename geometry_type_1, typename geometry_type_2> polygon_set_view<typename geometry_type_1::operator_arg_type, typename geometry_type_2::operator_arg_type, boolean_op::BinaryAnd, typename geometry_type_1::operator_storage_tag, typename geometry_type_2::operator_storage_tag> operator&(const geometry_type_1& lvalue, const geometry_type_2& rvalue) { return polygon_set_view<geometry_type_1, geometry_type_2, boolean_op::BinaryAnd, typename geometry_type_1::operator_storage_tag, typename geometry_type_2::operator_storage_tag> (lvalue, rvalue, polygon_set_traits<geometry_type_1>::orient(lvalue), boolean_op::BinaryAnd()); } In explanation of what is going on, the polygon_set_view just takes a const ref of each of its arguments and performs the actual algorithm only when its member function is called asking for the result, which it returns by reference because the view has a member to store the result of the algorithm. This has the nice side benefit of eliminating an unnecessary copy that would normally occur if the operator function returned the result of the algorithm by value (which could be very large.) An interesting feature of this design is that the polygon_set_view can accept an polygon_set_view in its geometry type template parameters leading to recursive template instantiation. You can see that in the test case below where the template instantiation recursion depth is equal to the number of chained operator calls made in a single statement. The drawback of the design is that I'll need to overload the operator functions to allow the user to register their own data types as operator arguments since the user geometry type can't be expected to provide a typedef for operator_arg_type. The overloaded operator would use a metafunction that registers the user type as an operator_arg_type. This leads to four declarations for each operator since either or both arguments can be of one flavor or the other. If you drop this miniature test into a cpp and compile against the gtl header files you should see that the compiler handles things nicely. I'm using gcc 4.3.0 to get maximal standard compliance. #include "gtl.h" int main() { polygon_set_data<int> ps1, ps2, ps3; ps1 | (ps2 | ps3); (ps1 | ps2) | ps3; ps2 * ps1; ps1 & ps2 - (ps3 + ps1) ^ ps2; return 0; } I have also changed the point_3d_concept to inherit from the 2d point concept and the polygon_with_holes_concept similarly inherits from the polygon_concept. This leads to a very convenient ability to produce polymorphism of generic geometry types. There are still a few more algorithms that need to be hooked up before the prototype of the re-implemented library is complete, but I wanted to ask for feedback now so that I can get early course correcting advice. The design is still in a state of flux. Thanks, Luke