Re: [boost] [concept_check] Some issues

Subject: Re: [boost] [concept_check] Some issues
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2011-11-25 20:05:59

> From: Stewart, Robert
> > - The implementation of assignable_archetype defines private
> > default and copy constructors, so for example
> > assignable_archetype<copy_constructible_archetype<>> will not
> > actually be copy constructible. The same for
> > convertible_to_archetype and convertible_from_archetype, but
> > additionally with copy assignment. Is this by purpose?
> 
> I should think that's by design.  The archetypes are to validate a
> particular concept checking class, so a copyable or default
> constructible archetype for Assignable would be wrong.

I wouldn't say it's wrong. If you can combine several concepts, you should
be able to combine the corresponding archetypes too. If your template
requires more than one concept (e.g., a type that is BOTH copyable AND
assignable), then without the ability of chaining you would have to write
your own archetypes in all but the most trivial cases.

> Are archetypes are supposed to be composable?

I guess they are since most of them have the Base template parameter.

> Even if so, not all combinations are possible.

Could you give an example of an impossible combination?

> > - copy_constructible_archetype defines public default
> > constructor - again, am I overlooking something or it should
> > not be there?
> 
> I wouldn't think so.
> 
> > - Function and predicate archetypes also seem to provide too
> > wide interface (they are copy constructible and assignable).
> 
> Since you're asking, and I haven't checked to verify it, I presume that
> those operations are not part of the corresponding concepts.  If so,
> then I agree they should not be available.

What should be done about this, then? Removing the superfluous functions may
break some tests, but I guess in this case it is even desirable because it
means the tests have errors that were undetected so far. I don't know why a
valid test would depend on a function that should not be a member of an
archetype.

> > Additionally, they don't allow for archetypes chaining since
> > they lack the Base parameter (with the only exception of
> > binary_predicate_archetype - why the inconsistency?)
> 
> Are they supposed to be generally chainable?

Actually I also wasn't sure before I wrote my previous mail and to verify
this I've written my own set of archetypes to test my library. They look
similarly to the ones in concept_archetype.hpp modulo all the issues I've
mentioned. They also don't provide any function implementations, only
declarations[*]. They seem to work fine with chaining. The only two
restrictions are:

- default_constructible_archetype must be on top of any other archetypes
that have any constructors (otherwise the constructors of the derived
archetype would prevent generation of default constructor),
- convertible_from_archetype must be the top-most archetype of all chained
archetypes (because constructors aren't inherited).

Note that there are no such problems with copy_constructible_archetype and
assignable_archetype because the functions are always generated
automatically (unless the base class doesn't have them or makes them
inaccessible - but no other archetype than the two should have them and the
only one that makes them inaccessible is null_archetype, which is always at
the end of the chain).

[*] Why the implementations are provided in concept_archetype.hpp, BTW? Are
there cases where concept checking programs should be linked, not only
compiled?

> > - Apart from the provided function object concepts and
> > archetypes it seems it would be useful to have a general
> > Callable concept and the corresponding callable_archetype,
> > parameterised with the types of arguments and return value.
> > Wouldn't it be valuable to add them?
> 
> That seems plausible and useful.

Other things I miss are: separation of predicate_archetype from
const_predicate_archetype etc. (currently implementation of the former is
actually the latter) and not requiring const arguments in
*_function_archetype (the constness can be expressed in the template
argument if needed).

Best regards,
Robert