"Chad Parry" <spam@chad.parry.org> writes:
"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.)
Whew; good luck with that one!
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.
That's might not be the best idea if you want the checker to be useful with C++98 generic libraries, which as a rule, don't make that requirement. Don't forget, when C++0x comes along, we'll have language support and a library solution won't be worth much.
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.)
Why don't you start with what I've already done to the library and work from there? I have already done quite a lot to improve the error messages and support associated types. It would be a shame to reinvent those wheels. Plus, we have a large suite of working concept checking templates based on real-world use cases (e.g. STL). As I implied in an earlier post, no matter how clever your system, if it doesn't handle the existing use cases well, it's a non-starter.
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. :)
One can do it, but I'm not sure it's really _worth_ doing. It's going to be at least a little inconvenient for users. It's almost impossible to get people to use concept checking _today_, despite its many benefits. I think you need to take care not to add too many barriers if you want your ideas to be adopted. -- Dave Abrahams Boost Consulting www.boost-consulting.com