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

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-10-11 08:25:56

2012/10/11 Dave Abrahams <dave_at_[hidden]>

>
> 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.
>

Note that N3351 addressed this problem of specifying expression type. You
can express this as:

  requires(Iter it)
  {
    Iter& == {++it};
    // is_same<decltype(++it), Iter&>::value

    ValueType<Iter>& == {*++it};
    // is_same<decltype(*++it), ValueType<Iter>&>::value
  }

Regards,
&rzej