On Wed, Oct 10, 2012 at 1:08 PM, Lorenzo Caminiti <lorcaminiti@gmail.com>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-discussi... https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-proposal... 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