Boost logo

Boost :

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-10-11 19:57:58

on Thu Oct 11 2012, Lorenzo Caminiti <> wrote:

> On Thu, Oct 11, 2012 at 5:25 AM, Andrew Sutton <asutton.list_at_[hidden]> wrote:
>>> Look for example at
>>> 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)
>> Can you produce those examples? You've made me curious.
> Andrew, what were the reasons in N3351 to move away from
> pseudo-signatures and toward usage-patterns?
> I red N3351 but if I had to summarize the rationale for the
> usage-pattern approach instead of C++0x concept's pseudo-signature
> then I'd say that N3351's argument is that its concept design for STL
> algorithms is "simpler" using usage-pattern than using C++0x
> pseudo-signatures. However, "simpler" is a subjective metric... I'm
> sure I'm missing something maybe reading N3351 one more time will
> clarify my thinking.

One other thing about this rationale: it doesn't appear to consider
what's simple for someone trying to write a generic algorithm. It's
easy to maintain that rationale when you don't have an implementation of
algorithm type-checking to force rigor on you. When you start working
with an actual implementation, and it refuses to compile "obviously
right" things like


because in fact, the requirements as stated do not guarantee that it
*should* compile, then your idea of what's simple may change. A usable
system has to be simple both for programmers modeling concepts and for
programmers using those concepts in generic code.

Dave Abrahams
BoostPro Computing                  Software Development        Training             Clang/LLVM/EDG Compilers  C++  Boost

Boost list run by bdawes at, gregod at, cpdaniel at, john at