On Fri, Oct 12, 2012 at 3:05 PM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Fri, Oct 12, 2012 at 6:25 AM, Andrew Sutton <asutton.list@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).
Then we all use the lib(s) to experiment with concepts before (re)proposing concepts (and hopefully contracts) for standardization in C++1x.
Experimenting is great. This is why I have Origin (https://code.google.com/p/origin/). I've been experimenting with concepts-as-a-library in various forms since 2009, and it only gets you so far. It's a very helpful if you want to develop a first pass at concepts for a library, and sometimes it pays off if you need to reason about some language feature interactions.
This is an extremely important point: emulating the concepts language feature with a library has its limits. Most of the hard problems with concepts, including the hard problems of making those concepts that we right actually model what we want---involve the type checking of template definitions. That type checking can be simulated with archetypes, but it's very hard to write archetypes that are as picky as what a compiler would come up with. That means that the concepts we write can't actually be validated against implementations, so it's hard to have any confidence in those concepts.
From the standardization perspective, we'll make zero progress until someone gets working on a real implementation. Just having a concept parser + archetype generator (which then instantiates template definitions based on those archetypes) would be a huge win.
This is intriguing. Based on my current experience with ConceptClang (and I could be missing something), I would actually argue that concept model archetypes (CMA) are the most essential component of any implementation of concepts -- N2914 or N3351 or else -- in that they are the essential glue to all components: 1. They link the requirements specified in concept definitions with their uses in the definitions of generic components. 2. They tell constraints satisfaction which concept model to look for or generate. Note that: 1. concept model checking reuses constraints satisfaction, and 2. entity reference rebuilding, at instantiation time, is not always necessary---since the need varies based on the design and implementation model. 3. When entity reference rebuilding is supported -- as in ConceptClang's current implementation of N2914 and some flavors of the N3351 implementation, then concrete concept models become particularly essential as well. In some sense -- and I'm still working on this idea, an implementation of CMAs can indicate the extend to which explicit concept models are needed to bind to customized implementations. That being said, independently of the concepts design, any parsing and checking of concept definitions should make the implementation of CMAs as easy as possible. There are other issues that I am currently finding with the semantics of checking entity references in restricted scope, in N2914, but that is something that I should perhaps leave for another discussion. In fact, I would like to run this by people who would be interest at the next committee meeting (next week). The bottom line is that, if I am right, then implementing the checking properly is a complex task -- either due to the implementation structure of Clang or just the nature of C++ grammar. (I'm not sure which one yet.) That complexity is, unfortunately, one of the main reasons for the hold up on deploying an updated version of ConceptClang. Thanks, -- Larisse.
- Doug
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost