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 17:37:18

On Wed, Oct 10, 2012 at 5:06 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> 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)
>>
> On simple cases this is not an advantage but there are cases that writing
> the pseudo-signatures is quite complex(or even impossible) if we don't want
> to say more than what the usage pattern says.
>
> for example
>
> f(a)
>
> requires that there is an unique overload of f that can be found for f(a)
>
> With pseudo signatures we could state that there is a function f with a
> parameter T and that a is implicitly convertible to T.
>
> void f(T) requires (Convertible<decltype(a), T>
>
> Note that a model that defines
>
> int f(A)
>
> satisfies the usage patter f(a) but not the pseudo signature. I don't see
> how to introduce the type R if it is not part of the concept parameters.

Actually, this all works with pseudo-signatures of N2914 and Boost.Generic.
Note that when you make a pseudo-signature such as

void f( T );

you are NOT requiring that the model in question has a signature that
matches exactly, nor that the return type must be void. The match is loose,
including convertibility of arguments and results, and if a return type is
specified as void in a pseudo-signature, it will match fine with functions
that do not return void (just don't try to use the return type as though it
were something other than void when in a constrained context).

>  - 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)
>>
> Well, this is always a problem for the concept developer as she needs to
> do this work once.

In N2914 this isn't really a problem even for someone creating a concept
since archetypes are automatically generated/used internally by the
compiler. The developer of a concept should not have to manually create an
archetype on their own.

> Has someone even think for one moment that we could use both mechanism,
> depending on the specific context.

I would love to have a chance to develop and use libraries built around
both approaches. At the very least, if Lorenzo and I get archetype
generation working with both approaches and coordinate a little bit, we
can, in theory, also create a macro for writing constrained algorithms that
works with either kind of concept. I'm not sure I'd like a library or the
standard to have both approaches only because they seem too redundant at
this point. I think I'd only be in favor of that if it can be shown both
that usage patterns can do something much more concisely and effectively
than pseudo-signatures as well as vice versa. If that can't be done, I'd
rather just have one or the other.

-- 
-Matt Calabrese