Boost logo

Boost :

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:
> [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

Boost list run by bdawes at, gregod at, cpdaniel at, john at