In the second preview of the library, there was also runtime indexing accessors, but they should disappear to only have compile-time accessors as shown above (I'm currently working on this with Barend).
There is no need to have both run time and compile time accessors, and you can do things with run time accessors that you cannot do with compile time accessors. The reverse is not true. I think you made the wrong decision and should consider making the accessors runtime only instead.
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.
Consider the difference between:
int get(array<int, 2> point, int index) { return point[index]; }
and
int get(const tuple<int, int>& point, int index) { if(index==0) return get<0>(point); else return get<1>(point); }
The latter look very ugly indeed, and it's precisely why I prefer compile-time access. Here are the same example with compile-time access: template <int I> int get(array<int, 2> point) { return point[I]; } and template <int I> int get(const tuple<int, int>& point) { return point.get<I>(); } This time, we access both structures as easily. Just because arrays and tuples are both accessible with a compile-time index, while tuples are not accessible with a runtime index. Adapting a struct { x, y, z } would be trickier in both cases, but looks more natural with compile-time indexes in my opinion (you map a compile-time stuff onto another compile-time stuff). 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. For me, the only advantage of runtime access is to be easier to use inside the library algorithms. As the writer of a library is not here to facilitate his own life but the user's life, this kind of advantage shouldn't be taken into account if it's the only one. This being said, if you have a precise example of algorithm that technically needs runtime indexing on points, could you please show it to me? I haven't been able to think of such a situation until now. If every algorithm of the library is able to work on compile-time indexes, so I definitely don't see why it would require runtime access. It would mean requiring more than actually needed, which is a no-sense for a concept. Regards Bruno