Boost logo

Boost :

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2012-10-14 05:07:43

On Sun, Oct 14, 2012 at 4:40 AM, Lorenzo Caminiti <lorcaminiti_at_[hidden]>wrote:

> It will have to be something like that, maybe with typename to
> distinguish from value template parameters as I mentioned before:

I have a little bit of magic that should allow me to handle this, relying
on template magic. I can detect whether a concept name corresponds to a
unary template with a type parameter as opposed to a non-type template
parameter via an overloading of certain function templates that occurs when
you create the initial concept. This isn't in yet, but proof-of-concepts
seem to work. The only complication with this is that since the check
occurs at compile-time (but not during preprocessing), the generated code
needs to be... complicated. It should in theory get rid of requiring the
user to make that specification, though.

Anyway, since probably 99% of the time the user is working with concepts
that have type parameters, I think we should aim to support that in a
concise manner. I.E. instead of requiring the user to write "typename" for
those concepts with type parameters, support it without typename and
instead require some alternative syntax for concepts with non-type
parameters, pending I can't get it all to work behind-the-scenes with the
same preprocessor syntax.

> Or, as I was saying, can't we just require the use of requires ;) instead:
> template( typename T, typename U )
> requires( ObjectType<T>, (MapType<U, T>) ) // (2)

Yeah, and that should be the main focus since it's easier to implement.

> Does Boost.Generic need ObjectType and MapType separately (as per 1)
> or it can use their instantiations Object<T> and MapType<U, T> (as per
> 2)?

In most contexts you can use their instantiations directly, and you should
be able to do so there. One place that may need to change is when dealing
with refinement (due to the changes I'm currently making, but I may be able
to come up with a hack). For example, in this concept:

I refer to less-refined concepts I.E. HasNegate<T>, but in order to make
explicit concept map templates for more-refined concepts work for
less-refined concepts in a truly N2914-compliant way, I may need to change
the syntax when doing refinement to something like (HasNegate)(T).

-Matt Calabrese

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