John wrote:
I want the flexibility to allow 'at' to return a reference. The references would then be to the underlying types internal members, which could be of any type.
Why? For a small type like a single coordinate value return by value will be efficient? Do you want the convenience of being able to use it to get a modifiable reference? What if the data type doesn't have an explicit data member, but computes it on demand and updates values it is computed from when it is modified through the accessor?
I have applications in mind where coordinates may be references to unsigned chars, so the type of the reference can not be the same type used for, say, an inner product.
I required only a 'scalar' type because I figure that is the minimal need. Coordinate elements, regardless of there raw types, need to be mixed, added, divided, etc.
Presumably things like euclidean norms are callable objects and something like result_of<euclidean_norm(Coord)>::type can be used to get or control its result.
You want such functions to be functor objects? Why not just let it be a function and create a functor from it when(if) you need one?
In my concept a coordinate_accessor is a UnaryFunction object an I should make sure ::boost::result_of works, huh..?
I guess it all depends on how far we want to go and how complicated we are willing to let it get. I'm driving at simplicity, elegance and minimal dependencies. I want user code to be as dead simple and straightforward to write as possible. I like the current idea of providing a library of free functions that infer types from their arguments using metafunctions and call the appropriate algorithm associated with the concept. Making functions into functors leads to a lot of extra boilerplate in both the library and the user code. I'd need to hear a good rationale for that.
Also maybe there needs to be Metric or Norm concepts to, eh?
I guess that depends on whether they are functions or objects. We would only want concepts for template parameters that may be supplied with user types. To that end, we need to be intentional about what is useful to be made generic rather than just making everything generic because we can. For me the concepts in the library serve two purposes. 1. They allow user types to interface with my heavy algorithms, easing and improving the quality of integration of those capabilities into an application. 2. They provide the user with a set of useful behaviors for geometry objects that are superior to what they are likely to have on their own types. By superior I mean completeness, consistency and ease of use. The only things that need to be made concepts, in my view, are geometry data types, not algorithms or behaviors. Thanks, Luke