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

Subject: Re: [boost] [contract] concepts: pseudo-signatures vs. usage patterns
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-10-11 05:51:52

2012/10/10 Matt Calabrese <rivorus_at_[hidden]>

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

"The match is loose" -- I believe that this "loose match" may be a problem
in itself. The pseudo-signatures look like any other signature so one might
expect that  they also work as any other signature. One would be surprised
to learn they are only similar with other signatures on the surface, but
differ in semantics due to this "loose match". In contrast, with usage
patterns you are already alerted with the unusual syntax that the meaning
of the declarations is unusual.

My comment may be very superficial though. I do not know pseudo-signatures
in-depth. And I do not find pseudo-signatures nferior. I only argue with
this "loose match" idea.

Regards,
&rzej