John wrote:
Oh, maybe my point of view was too narrow then :) In _this_ context I thought checking was a requirement, otherwise why make a class? without checking it is just documentation right?
Um, not in my case. I am sort of stretching the concept class to serve additional roles, for instance, making it also the scope within which functions related to that concept are defined.
<snip>
John wrote:
So what I am interested in is making those assumptions explicit, and providing the tools to check that my _own_ private code is going to work with whatever makes it into boost. That is why I say I care more about concepts (meaning checkable concepts & archetypes) than I do about the algorithms in a boost geometry library.
If your own point type has a default constructor and API sufficient to get and set the x and y values in any way you like it will work with my library. You would simply specialize the point_traits for your type and provide a typedef for your coordinate_type and two functions, one to get a coordinate and one to set a coordinate.
So would it be fair to say you aim to provide a 'concept_map' from some user type to a point-coordinate 'concept'? In that case, what I care about is the concept for the mapped type, since that is what I need to check my code against. -- John