From: David Abrahams (dave_at_[hidden])
Date: 2006-08-22 16:45:18
"Chad Parry" <spam_at_[hidden]> writes:
> "Douglas Gregor" <doug.gregor_at_[hidden]> wrote in message
>> On Aug 20, 2006, at 11:48 PM, David Abrahams wrote:
>>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk