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

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2012-10-14 13:30:19

On Sun, Oct 14, 2012 at 2:07 AM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> 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.

I'd prefer the syntax to allow the pp to distinguish between the
different kind of template params (that might not be required for
Boost.Generic but it might be required by other back-ends). In any
case, I understand your point and let's continue this discussion
if/when I start impl the macros -- at that time we will finalize all
the details of the syntax including this one.

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

And maybe we just support the requires clause and we don't have to
worry about typename or no typename in the template parameter
signature...

>> 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:
>
> http://generic.nfshost.com/generic/standard_concepts/concepts/arithmeticlike.html
>
> 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).

--Lorenzo