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-11 19:50:27

on Thu Oct 11 2012, Andrzej Krzemienski <akrzemi1-AT-gmail.com> wrote:

>>
>> >
>> >   "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)?
>>
>
> I think such comparison looks different when you want to provide the best
> solution for STL and different when you want to provide the solution for
> *every* generic library. STL is particular in two ways: first, it has been
> in use for years, and any solution needs to fit seamlessly into the
> existing code (even if the code doesn't adhere to the best practices of
> generic programming); second, STL uses operators heavily. I expect no other
> generic library to make such extensive use of operators.

That's a very surprising statement.  Many applications of genericity
seem to fall into mathematical domains.

> I have never tried to implement support for any type of concepts, so I am
> only looking at the problem from end user's perspective; arguments like
> "pseudo-signatures make it easier to generate archetypes" do not appeal to
> me that much (which admittedly may be an ignorant approach).
>
> Informally, I can say that I expect of an iterator a post- and
> pre-increment, comparison, and dereference. With pseudo signatures I
> express it as:
>
>   Iter& operator++(Iter);
>   Iter operator++(Iter, int); // note the dummy int
>   bool operator==(Iter const&, Iter const&); // bool or convertible to bool?
>   ValueType<Iter>& operator*(Iter const&);
>
> But how do I say "convertible to bool"?

You just said it :-)

> With usage-patterns, I type:
>
>   Iter& == { ++it };
>   Iter == { it++ };
>   bool = { it == jt }; // convertible
>   ValueType<Iter>& == { *it };
>
> To me, the latter notation appears more appealing: it is shorter, it gives
> me a concise way of specifying "has exactly this type" or "is implicitly
> convertible to" or "is explicitly convertible to". 

But you don't want to say those things.  When you say "is implicitly
convertible" and you don't have the pseudo-signature loose/tight
mechanism behind it, the obvious, clean way to express your algorithms
doesn't compile, and you need to uglify them by inserting explicit
conversions.

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