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