Re: [boost] Report from Berlin C++ Standards Committee meeting

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2006-04-10 16:35:09

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Doug Gregor

> Imagine a world where the compiler type-checks your templates 
> when you define them, so that no type errors slip past until 
> instantiation time. A world where misuse of template 
> libraries results in 2-line error message instead of a 
> 2-megabyte error message, where user errors are diagnosed as 
> user errors and implementor errors are diagnosed as 
> implementor errors. Imagine throwing away all of that 
> imprecise concept documentation we use, replacing it with 
> precise concept definitions checked by the compiler. Imagine 
> composing generic libraries together without writing a single 
> adaptor class, where it doesn't matter if I call it 
> "x.size()", "size(x)", or "length (x)".  And do it all 
> without breaking existing code.
> 
> Concepts will drastically improve our ability to write solid 
> generic libraries in C++. When we've improved our compiler 
> and introductory material, we'll announce the next release of 
> ConceptGCC. I strongly encourage everyone interested in 
> library design to give it a try.

Doug, is there an up-to-date paper on concepts?  If so, maybe some of the
serious problems associated with earlier concept mechanism ideas have been dealt
with.  Concepts, as I've seen them so far, are not simply "everything is better"
like you appear to be implying above.  Given what I have seen, let me add to the
above:

Imagine a world where either 1) copious amounts of implementation detail bubbles
up the hierarchy of concept requirements, 2) the 2-megabyte error messages we
get now are replaced with 2-megabyte error messages of concept failures deep in
the hierarchy of concept requirements, or 3) ad-hoc polymorphism, the greatest
strength of the template mechanism in C++, is simply dropped in favor of, at
best, non-extensible lists of alternatives.

IOW, I've yet to see a concept mechanism that could even be used to implement
the STL (about the simplest possible example) with the same degree of
extensibility that we have now.  Maybe a concept mechanism can be designed that
minimizes how much extensibility is lost, but either way, it's hardly the
all-around-win-scenario that you're implying above.

Perhaps my understanding is out-of-date.  If so, corrections are welcome.
However, my opinion (watching this from the very beginning) is that concepts are
fundamentally at odds with ad-hoc polymorphism and second-phase lookup.  In
order to do it, you have to make significant concessions in those two areas--and
I doubt this has changed.

Regards,
Paul Mensonides