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

From: Doug Gregor (dgregor_at_[hidden])
Date: 2006-04-12 08:44:42

On Apr 12, 2006, at 6:05 AM, João Abecasis wrote:
> Paul Mensonides wrote:
>> That's what I'm referring to when I say "bubbling of  
>> implementation detail."
>> Note, in particular, that CopyConstructible is not sufficient as a  
>> sole
>> requirement of g or h.  f is needed in the requirements of g, and  
>> both f and g
>> are needed in the requirements of h because both are bound during  
>> the second
>> phase--which could result in (e.g.) an ambiguity.  You need to  
>> raise that (e.g.)
>> ambiguity to the top-level instantiation (or concept check  
>> immediately prior to
>> instantiation) in order to avoid the two-megabyte error messages  
>> (whether they
>> be in regular templates or in concept checks).
>
> It is my understanding that requirements are to be maintained by the
> developer. This only follows existing practice with, e.g., enable_if,
> static_asserts and tag dispatching. It is still up to the developer to
> keep those requirements accurate and up-to-date. Otherwise the  
> compiler
> will "fallback" to the two megabyte error message.

Concept requirements are a little stronger than that. If your  
requirements are wrong on a given function template, that function  
template will fail to type-check when it is defined. The typical  
example I use is:

template<InputIterator Iter, typename F>
   where Callable1<F, InputIterator<Iter>::reference>
   F for_each(Iter first, Iter last, F f) {
     for (; first < last; ++first)
       f(*first);
     return f;
   }

The compiler will reject this definition of for_each, because there  
is no operator< that works on Input Iterators. Change the "<" to a "! 
=", and all is well.

So, Paul is right that your requirements need to reflect what your  
implementation does. But, you are also correct that this is the  
current state of affairs--except that today we use documentation to  
describe requirements, whereas concepts allow us to use code to  
describe requirements.

        Doug