Hello, Luke, I come back to you about this point from you:
Also, your get function returns a reference to coordinate. It should return by value. Many legacy point types may have a public API that prohibits direct access to their members because that is what good little C++ programmers were taught to do in school. Those point classes could not conform to your concept.
If you are talking about using the getter for read access, this way of writing traits specialization is not an obligation and the user can always return by value in his own one. If you are talking about using the getter for write access (that is: get<0>(p) = value) it's more problematics. We've discussed about that with Barend and it appears that as you say, a legacy point without direct access to its coordinates will never be adaptable to such traits. I hadn't thought about that before. The problem is that this approach (value = get<0>(p) for read access and get<0>(p) = value for write access) has been chosen after having been advocated by some people on this list. The argument was that it is a very common approach in Boost, for Tuple and Fusion. And this argument was quite convincing. Must I deduce that the Boost.Fusion approach is not totally generic and that a structure with unreferencable private members couldn't be adapted to it? And what would finally be the best way to handle point write access if the Boost.Fusion one is wrong? Thanks Bruno