Fernando wrote:
Acutally, that to_int() is getting back into runtime, so this wouldn't count as a compile-time access even if it compiled.
Well, yes, I did say it wouldn't compile, so I figured I wouldn't follow the rules. Allowing the type to auto-cast to int breaks down the type safety (since it allows unintended conversions.) The point was to show that type safety (not allowing conversion or orientation to and from int) is incompatibile with the compiler requirement that the parameter be a built in type.
OTOH, this could be made to compile if desired: struct horizontal{ static const int value = 0 ; } template <class orient> coordinate get(const point& pt) { return pt[orient::value]; } coordinate value = get<horizontal>(my_point);
Since template metaprogramming is turing complete we can envision implementing the entire set of runtime behaviors of the isotropic objects in my library as compile time behaviors which would lead to a truly dauntingly complex (potentially fun) exercise in template meta-programming. It might result in a functional library, but would raise the bar for learning and using the library pretty much all the way up to where only intellectual giants can reach it.
then it should advocate higher level abstractions: vector delta = condition ? vector(value,0) : vector(0,value) {} translate modify (delta); point = modify(point); which, being essentially coordinate-free, hides the coordinate-access issue from the user pushing into the library implementation.
I am guessing translate is a class, modify is an object of that class that is constructed from a vector and provides a operator() which takes a point, translates it and returns the translated point. In fact, this is quite close to the kinds of things we do. If you grep for predicated_value in my vault submission it is a standin for ? syntax, and used quite heavily. This is what we are, in fact, advocating people do, and the isotropic types are often the condition (as you can well imagine.) The idea is to make the user code coordinate-free as much as possible, allowing them to work at a higher level of abstraction and pushing the low level details into the library (other than the heavy algorithms, that is the service I'm providing with the library.) I don't agree that it won't matter to the user what accessors look like inside the library. I don't think I can completely abstract away the existence of coordinates, nor do I want them to have to rely on their own legacy interfaces. Preferably, the user should feel empowered to extend the library by writing in its style to suit their need. From that standpoint, the style shouldn't be allowed to become unnecessarily complex. Thanks, Luke