Hello, I haven't been able to participate to this already well advanced discussion since I was off at the moment. If I summarize, I basically agree with the conclusions given in the latest posts. I will only quickly answer the questions asked me at the beginning.
I precise that it's not a final decision, just an idea. But my guts feeling is that compile-time access is a weaker requirement than runtime access, so in the idea that a concept must always model the *minimal* requirements, compile-time should be preferred.
In what way weaker? This implies that there should be a type that can provide compile time access, but can't meet the stronger requirement and provide runtime access. Can you produce such a type?
boost::tuple is such a type. The whole idea is that whenever runtime access is available, compile-time access is easily providable, while the inverse is not true (unless with series of if statements). So compile-time requirements are easier to satisfy than runtime requirements. This is what I have in mind when I say that compile-time access is more "minimalistic" than runtime access. Keep in mind that I'm really talking about the moment when the user has to provide a compatible point from the data type he's working with. As said earlier in this thread, he can still use his runtime accessors in his own code.
As pointed out by John, another advantage of compile-time access is the ability to have different types for each coordinate. It's something that has been asked for several times during recent discussions on this list. I was even wondering the other day if it wouldn't be better to not require any coordinate_type typedef and have the algorithms deducing by themselves the type of each coordinate by a BOOST_TYPEOF on the accessor.
Hmmm, that does inspire some thought, doesn't it? At some point, though the different coordinate types need to be used together and the result will be auto-casting. It seems reasonable to me to declare the coordinate type of an object with heterogeneous coordinates as the one to which the others will auto cast when used together. Clearly, this could be bad if you mix signed and unsigned, but that would end badly eventually anyway.
I wasn't thinking about letting the compiler cast everything by itself, but rather using precise type promotion rules when needed. But it's just an idea for now, I have only noticed that some people do require the ability to use heterogeneous data types. Regards Bruno