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

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2012-10-10 17:36:14

On Wed, 10 Oct 2012, Vicente J. Botet Escriba wrote:

(snip)

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

Where would you get "a" from in this context in a pseudosignature?
Assuming you had it (for example, it was the result type of an
expression built using declval), you could write:

void f(decltype(a));

and any f that can be called on a value of type decltype(a) would
automatically be found (either in the outer scope or in a concept map).
Additionally, if you called this f from a constrained template, you
would always get the version that took decltype(a), even if what you
called f with would need to be implicitly converted to decltype(a) to
use that function (and you would not get any other overloads of f that
are more specialized for the actual type you called f with in the
constrained template).  Similarly, if you write:

bool operator==(T, T);

in a pseudosignature, you can assume that the type you get back from a
call to this function in a constrained call will be exactly bool, not
some type convertible to bool.  If the operator== found in the
surrounding context (for an auto concept) had a different return type,
the one in the generated concept map would have a compiler-inserted
conversion to bool wrapped around it.  This applies to the
convertibility syntax in N3351 as well, I believe.

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

The use pattern syntax does not provide a way to write archetypes
manually; if you wanted to do archetype-style checking of constrained
templates outside particular uses, you would need to have a compiler
that generated archetypes or used similar techniques for checking.

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

It would be possible (you can translate automatically in either
direction, especially with the return-type syntax for use patterns in
N3351).

-- Jeremiah Willcock