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

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2012-10-10 15:17:20

On Wed, Oct 10, 2012 at 1:08 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:

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

We should possibly take this discussion to
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-discussion

https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-proposals
as
Dave suggested in the other thread.

First, some initial properties -- some of these aren't really clear pros or
cons, just differences as they come to mind, unorganized. I am not on the
standards committee and am definitely not an expert concerning the
usage-patterns approach, so other people would probably be able to produce
much better lists than these (it'd be nice to have I.E. Doug Gregor and
Andrew poke their head in here, but I know they're busy). I'm also biased
toward pseudo-signatures, as is Dave at least (I don't know about Andrzej),
so we really need someone more committed to usage-patterns to be able to
highlight the benefits and drawbacks.

Usage-patterns:
- Usage-patterns show valid expressions and properties of expressions that
deal with the concept's arguments (mostly subjective if this is pro or con)
- Concept definitions are very different syntactically from other
definitions in C++ (possible con)
- An Individual required usage pattern may be more complicated than a
single function call (possible pro)
- A usage patterns cannot have a default implementation (con)
- The use of givens more closely matches the way concepts were specified in
previous standards (pro, though this only realistically affects people who
deal with the standard)
- Exactly what types of argument can be passed to associated functions may
not be apparent to the user since since you have to deduce a function
declaration based on the types of the givens (and consider convertibility,
etc). (con)
- Generation of sensible archetypes is not immediately apparent (at least
to me), particularly when considering associated function parameter types
since again, those types would have to be deduced from arguments being
passed, not a function signature. (con)
- N3351 doesn't mention archetypes at all (*cough* they're important
*cough*) (con)

Pseudo-signatures
- A concept definition looks and "works" very similarly to the definition
of a type that models the concept being defined (IMO big pro)
- Writing and reading a generic algorithm that deals with a concept is very
similar to writing and reading an algorithm that deals with a type
definition since you are essentially writing to an archetype (pro)
- Pseudo-signatures can have defaults (pro)
- noexcept being applied to an associated function requirement is very
simple to do with pseudo-signatures in the same way that you'd augment a
regular function declaration (though N2914 didn't yet have noexcept) (pro)
- Concept definitions do not look like the way concepts were specified in
previous standards (con)
- "Proper" archetype generation from pseudo-signatures is much more clear
than with usage-patterns, though usage patterns here may not be as bad as I
am imagining (pro)
- Archetypes are fundamental to N2914 (pro)
- This approach made it very far through the standardization process and
its language/library components were chiseled into what ended up in N2914

Again, I am biased toward the pseudo-signature approach, so I may not be
giving usage-patterns the representation that they deserve. Also, while I
have a lot of experience emulating N2914 in C++11 and know it very well, I
would not consider myself an expert.

-- 
-Matt Calabrese