On Thu, Oct 11, 2012 at 9:51 PM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
Right now I see two ways forward:
1. I implement N3351 in Boost.Contract and Matt implements N2914 in Boost.Generic. 2. Or, I help Matt implementing N2914 in Boost.Generic (and Boost.Contract's requires clause will use concepts defined using Boost.Generic).
I'm all for either of these ideas. Also, I've finally started documenting the concepts in Boost.Generic (they are all of the concepts of N2914, not all working though). It's in the sandbox and uploaded at http://generic.nfshost.com/ , but don't try to build the docs from the sandbox because they rely on some code changes that I have yet to commit. Fixing explicit concept maps that deal with refinement is proving to be a little tricky. I'll prioritize making a simple tutorial so that people have some idea as to how to work with the concepts without looking at the boostcon slides or the library's tests. At the very least, if you click through the concepts that I have documented (all of concepts, support_concepts, and container_concepts), you can see the syntax... albeit littered with little comments, workarounds, and TODOs since the code just references the source. Then we all use the lib(s) to experiment with concepts before
(re)proposing concepts (and hopefully contracts) for standardization in C++1x.
It would be very interesting to do something like implement BGL concepts and constrained algorithms with both N2914 and N3351 approaches through Boost.Generic and Boost.Contract, then encourage people to experiment with the results. -- -Matt Calabrese