Re: [boost] Yet another concept checker

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 
> news:ECF14E7B-BC49-4021-9828-A1EF57C862E9_at_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:
>>
>> http://www.generic-programming.org/languages/conceptcpp/
>>
>
> 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