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

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-10-10 20:09:07

on Wed Oct 10 2012, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:

> On Tue, Oct 9, 2012 at 7:16 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>> on Tue Oct 09 2012, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:
>>>
>>> I made a first attempt to sketch how N3351-like concepts will look
>>> into Boost.Contract (just for the find algorithm and its concepts for
>>> now):
>>> [...]
>>> Please tell me what you think now
>>
>> Since you asked what I think,
>>
>>   "pseudo-signatures > usage patterns"
>
> Hello all,
>
> Can we write down pros and cons for concepts implemented via
> pseudo-signatures (C++0x-like and Boost.Generic) vs. usage patterns
> (N3351 and Boost.Contract)?
>
> Who wants to start? Matt, Dave, Andrzej, ... I can compile a qbk table
> with what we discuss.

Matt C. already mentioned the ease of producing a new model of a given
concept.  I will mention that usage patterns tend to leave unstated
assumptions about intermediate associated types that make it very hard
to be sure you're saying what you really mean, and tend to lead to
semantically-vague requirements.  Look for example at
http://www.sgi.com/tech/stl/find_if.html.  I can easily satisfy all the
stated requirements and produce an example that won't compile.  I can
also easily fail to satisfy the stated requirements and produce an
example that *will* compile.  That's because there's a great deal of
potential mischief hiding in expressions such as 

  f(*p)

[For example, what is the relationship between the type of *p and the
iterator's value type?  What is the relationship between that type and
the argument type of the function object? Even if the reference
type of p is convertible to the argument type of f, the call can still
be ambiguous... etc...]

This is a perfect example of what you get when you deal in usage
patterns, and the C++98 (and even the '03) standard is full of these
problems.  One of the most important features of the pseudo-signature
approach is that it injects implicit conversions to (explicitly-stated)
associated types, so these issues don't arise.

I don't know how to make a tidy little bullet out of this issue for your
list of pros and cons, but I think it's the most important one on the
list.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost