1. Prefer metafunctions in the point concepts requirements over traits classes, or I'm afraid the traits will get huge.
If the traits are huge the abstraction is being made in the wrong place. A good abstraction is a min-cut in a graph of dependencies. A huge number of metafunctions seems equally bad to me. Instead the goal should be to minimize the number of traits/metafunctions required to be understood/specialize by the user.
I know the principle of avoiding blob traits, as exposed in Abrahams and Gurtovoy's book. But I think it doesn't apply here just because the traits in question is *way* short. A type, a value, an accessor. And most algorithms need all of them. Does it really make sense to scatter them into several metafunctions??
2. Put your concept mapping functions in a namespace rather than a class (do it like like Fusion does). Namespaces seem to provide a lot more flexibility, and the syntax is a LOT cleaner.
I am considering the implications of your suggestion. It could be that it can be made to work, but I'm not clear on how overloading functions in a namespace is preferable to specializing a struct. It seems that it is more prone to compiler errors related to overloading ambiguity caused by bad user code and unfortunate combinations of user code. With the traits there is no chance for ambiguity.
I agree with Luke on this point, I'm afraid about nightmares that overloading ambiguities could bring to the user. However, I will consider doing a few tests to see the actual consequences of what you propose.
3. Provide separate headers for each metafunction. This allows users to fucus on metafunctions that matter.
I am doing this already, though there is only one metafunction that matters right now; the one that maps the user type to its related concept.
Same remark as above: one metafunction and one separate header of each of the 3 properties needed, I wonder if it's not a bit overkill...
4. Make all requirements explicit in the concept class. This way I can look at the concept code and see what they are.
Aren't the requirements explicit enough in the concept class I've shown? If not, could you be more precise on what you'd like to see more clearly specified? Bruno