Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Andrew Sutton (asutton.list_at_[hidden])
Date: 2012-10-11 17:45:50

> Doesn't compile, but "should"
>
>   struct Predicate
>   {
>       typedef char argument_type;
>
>       bool operator()(char) const;
>       bool operator()(long) const;
>   };
>
>   std::vector<int> v(10);
>   std::vector<int>::iterator p = std::find_if(v.begin(), v.end(), Predicate());

I don't think it should compile. Predicate doesn't seem like it can be
called with an int in any context, so a concept that catches that
seems to be doing the right thing.

> If you take the standard definition of "input iterator" instead of the
> SGI one, the examples are even more compelling, because the result type
> of "*p" merely has to be "convertible to T", so it's easy to arrange a
> Predicate with no overloads that fails to accept the argument because
> too many implicit conversions are required.
>
> For the "shouldn't compile, but does" example I was presuming the
> standard definition of "input iterator;" just make an input iterator
> that returns a type X convertible to the value type, and make the
> predicate's operator() accept X but not the value type.

I can see how those might be problematic. I'll have to tinker with
some concrete examples to get a better understanding.

Andrew