Well this is interesting. I've looked some more at your docs and I see that you really haven't used e.g. Boost.Polygon's Point concept at all. Instead you have your own concepts; IIUC, having read the "Basic Tutorial" page, your Point concept requirement is
To make it clear there is no such thing as Boost.Polygon.Voronoi Point. The library would work with any point class that supports x() and y() access methods at the moment. So I'd be interested to know what has happened in this case. Is it simply
that the extra work to use the generic style is too much to ask of the author? (At the time of the review, I had the impression that this style was making life unreasonably difficult for potential library contributors, but I think I was convinced by others that this was worthwhile in order to get more uptake in existing code.) Or is there some other factor that I've missed?
I didn't consider this before as this will require just one small change in the Voronoi builder initialization method. So if this is a permanent requirement for the inclusion I'll do the proper updates. On the other hand I really like current interface as it is very simple and allows to construct Voronoi diagram with one include header and two lines of code. I am wondering if there is a solution that will satisfy both sides. For example changing default implementation of point_traits: template <typename T> static inline coordinate_type get(const T& point, orientation_2d orient) { return point.get(orient); } to: template <typename T> static inline coordinate_type get(const T& point, orientation_2d orient) { return (orient == HORIZONTAL) ? point.x() : point.y(); } This will support my current template interface that accepts anything with x(), y() methods by default and won't break functionality of the Boost Polygon library. Am I right? Regards, Andrii