"Douglas Gregor" <doug.gregor@gmail.com> wrote in message news:ECF14E7B-BC49-4021-9828-A1EF57C862E9@cs.indiana.edu...
On Aug 20, 2006, at 11:48 PM, David Abrahams wrote:
[snip]
Well, it looks really interesting (really!), but I think you should review the ConceptC++ publications, in particular N1849, before investing more time in it. Also, IMO, you should try to model the standard concepts and see how it works out in practice.
I strongly suggest that we focus on the latest concept proposal, N2042. N2042 is the result of countless hours of discussions among the authors of the two different concepts proposals, and it is the only concepts proposal that will be moving forward.
You can find up-to-date information on the concepts proposals, compiler, etc. on the ConceptC++ home page:
That's exactly the kind of feedback I was hoping for. I'll focus more of my attention on these items you brought up: 1) Try to mimic the declarative syntax rather than the use pattern syntax. (There's probably no reason why both can't be supported simultaneously in a library solution like this.) 2) Require authors to declare that their types model a concept; don't assume matches based on syntax. Allow for concepts to be declared with the opposite default behavior if they wish. 3) Try to make the errors user-friendly. 4) Add support for associated types. (I've already thought a lot about this and it won't be too hard.) 5) Improve the user experience for signatures that are known to be undetectable by library code. This includes the DefaultConstructible<T> concept, for example. I've already thought a little about this. I know how to elegantly encode requirements like Swappable<T, U> but I'll save that for another post. :) Thanks for the encouragement! I'll report again when I have made some progress. In the meantime, anyone who replies to me privately is welcome to have access to the sources. -- chad