On Wed, Oct 10, 2012 at 5:06 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> 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