Edit: Please disregard this post - After studying clangs algorithm for partial ordering as implemented by Doug Gregor (even though it is only partially implemented as of this writing - it seems that the logic that's relevant to the OP's question is implemented adequately enough) - it appears as if it treats the undeduced context as just another template parameter. Which suggests that the overload with the explicit void* argument should be the more specialized version and there should be no ambiguity. As usual Comeau is correct.
Now as for the wording in the standard that clearly defines this behavior - that's another matter ...
Since this post was also posted on comp.lang.c++.moderated, and seems to be causing some confusion there too - i thought i'd post my answer to that group here too - since the discussion is obviously relevant to the question asked here.
On Jul 25, 1:11 pm, Bart van Ingen Schenau <[email protected]> wrote:
You are going one step too fast here. How do you know (and would the compiler know) that there is no specialisation of Const<Q> such that Const<Q>::type != void?
As far as I can see, the compiler would transform the parameter-list of A to: AT=(Q, <unknown>*). To call B with these parameters requires an implicit conversion (<unknown>* to void*) and therefore A is less specialised than B.
I believe this is incorrect. When checking to see which function is more
specialized (during partial-ordering), the compiler transforms the
parameter-list to (Q, void*) - i.e. it actually instantiates the relevant
template (best matching) and looks inside it for the value of 'type' - in this case, based
on the primary template, it will be void*.
Regarding your point concerning partial specialization - when checking for
which template is more specialized than the other, the only type that can be used
is the unique generated type - if there are other specializations at the point
of instantiation of the declaration (when overload resolution is being done)
they will be considered. If you add them later, and they should get selected
you will be violating the ODR (according to 14.7.4.1)
The partial/explicit specializations will also get considertaion during
formation of the candidate set - but this time using the types of the actual arguments
to the function. If the best matching partial specialization (of X) results in a
function type that has a better implicit conversion sequence for some
parameter, then we never make it to the partial-ordering phase, and that
"better" function will get selected (before making it to the partial
ordering phase)
Here is an example with comments about what should be going on at various steps:
template<class T, bool=true> struct X; // Primary
template<class T> struct X<T,true> { typedef T type; }; // A
template<> struct X<int*,true> { typedef void* type; }; // B
template<class T> void f(T,typename X<T>::type); //1
template<class T> void f(T*,void*); //2
int main()
{
void* pv;
int* pi;
f(pi,pi);
// two candidate functions: f1<int*>(int*,void*), f2<int>(int*,void*)
// Note: specialization 'B' used to arrive at void* in f1
// neither has a better ICS than the other, so lets partially order
// transformed f1 is f1<U1>(U1,X<U1,true>::type) --> f1<U1>(U1,U1)
// (template 'A' used to get the second U1)
// obviously deduction will fail (U1,U1) -> (T*,void*)
// and also fails the other way (U2*, void*) -> (T,X<T>::type)
// can not partially order them - so ambiguity
f(pv,pv);
// two candidate functions: f1<void*>(void*,void*), f2<void>(void*,void*)
// Note: specialization 'A' used to arrive at second void* in f1
// neither has a better ICS than the other, so lets partially order
// transformed f1 is f1<U1>(U1,X<U1>::type) --> f1<U1>(U1,U1)
// (template 'A' used to get the second U1)
// obviously deduction will fail (U1,U1) -> (T*,void*)
// and also fails the other way (U2*, void*) -> (T,X<T>::type)
// can not partially order them - so ambiguity again
}
It's also worth mentioning that if the primary template does not have a definition - then SFINAE operates during the partial ordering phase,
neither can be deduced from the other, and ambiguity should result.
Also if you add another template that would lead to another match if the point of instantation of either of those functions is moved elsewhere in the translation unit you will clearly violate the ODR.
On Jul 25, 1:11 pm, Bart van Ingen Schenau <[email protected]> wrote:
First, being more specialised means that these are fewer types where
that template can be selected by overload resolution.
Using this, the rules for partial ordering can be summarised as: Try to
find a type for A such that A can be called but B not, or overload
resolution prefers to call A. If that type can be found, then B is more
specialised than A.
No argument here.
But based on the rules as they are currently, the OP's example has to be
ambiguous.
Finally, here are explicit, unambiguous answers to the two specific questions raised by litb:
1) Will this now use the value of T deduced for the first parameter?
Yes - of course, it has to, it is doing template argument deduction -
the 'links' have to be maintained.
2) Now, why do the implementations say that the second is more specialized instead?
Because they are wrong ;)
I hope this puts the issue to rest - Please let me know if there is anything that is still unclear :)
Edit:
litb raised a good point in his comment - perhaps stating that the primary template will always get
used for the instantiation with the unique generated type is too strong a statement.
There are instances where the primary template will not be called.
What I am getting at is that when partial ordering is occuring, some unique generated type is
used to match the best specialization. You're right, it doesn't have to be the primary template.
I have edited the above language to do so.
He also raised an issue regarding defining a better matching template after the point of instantation.
That will be a violation of the ODR according to the section on point of instantiation.
The standard says that once the A/P pairs are created (using the rules of transformation as described in temp.func.order) they are deduced against each other using template argument deduction (temp.deduct)- and that section handles the case of non-deduced contexts, instantiating the template and its nested type, triggering points of instantiations. The temp.point section handles the ODR violations (the meaning of partial ordering should not change regardless of the points of instantation within a translation unit). I'm still not sure where the confusion is coming from? – Faisal Vali 1 hour ago [delete this comment]
litb: "Note that the step that puts Q into Const::type to build the arguments is not covered explicitly by the SFINAE rule.
The SFINAE rules work with argument deduction, put the paragraphs that put Q into the function template function parameter list are at 14.5.5.2.'
The SFINAE rules have to be used here - how could they not be?
I feel it is sufficiently implied - i won't deny that it could be clearer, and while i encourage the committee to clarify
this - i don't think it needs to be clarified to interpret your example sufficiently.
Let me provide one way to link them.
From (14.8.2):
"When an explicit template argument list is specified, the template arguments must be compatible with the
template parameter list and must result in a valid function type as described below; otherwise type deduction
fails"
From (14.5.5.2/3)
"The transformation used is:
— For each type template parameter, synthesize a unique type and substitute that for each occurrence of
that parameter in the function parameter list, or for a template conversion function, in the return type."
In my mind, the above quote implies that once you "create" unique generated types for each template parameter, the function declaration has to be
implicity instantiated by explicitly supplying the unique types as template arguments to our function template. If this results in an invalid
function type, then not only the transformation, but more importantly the subsequent template argument deduction necessary to
partially order the function fails.
From (14.5.5.2/4)
"Using the transformed function parameter list, perform argument deduction against the other function template. The transformed template
is at least as specialized as the other if, and only if, the deduction succeeds and the deduced parameter types
are an exact match (so the deduction does not rely on implicit conversions)."
If the transformed function parameter list leads to substitution failure, then we know deduction could not have succeeded.
And since deduction did not succeed, it is not as specialized as the other - that is all we need to know to proceed
in partial ordering the two.
litb: I'm also not sure what happens in this case: template<typename T> struct A;
template<typename T> void f(T, typename A<T>::type); template<typename T> void f(T*, typename A<T>::type); surely,
that's indended to be valid code, but doing A::type, it will fail because at the
template definition context, A isn't defined yet"
Also note that there is no POI defined for template instantiations resulting from this
kind of substitution while trying to determine an ordering (partial ordering does not depend
on any context. It's a static property of two function templates involved).
I think this looks like a problem in the Standard which needs to be fixed.
Ok - i think i see where we are seeing things differently. If i understand you correctly, you are saying that
as these function templates get declared, the compiler is keeping a track of the partial ordering amongst them,
regardless of overload resolution ever getting triggered to select between them.
If that is how you interpret it, then i can see why you would expect the above behavior you describe.
But I do not think that the standard ever requires or mandates that.
Now, the standard is clear that the partial ordering is agnostic to the type that is used in calling the function (I believe
this is what you are referring to when you describe it as a static property and it being context independent).
The standard is also clear that it only cares about partial ordering (invokes partial ordering) between function templates
during the process of overload resolution (13.3.3/1) if and only if it could not pick the better function based on ICS's or
if one is a template and the other is not. [Partial ordering of class template partial specializations is a separate issue
and in my mind uses the relevant context (other template definitions) that requires the instantiation of that particular class.]
Thus, in my opinion, since the machinery of partial ordering of function templates is invoked when overload
resolution is performed, it has to use a relevant portion of the context (template definitions and specializations) available
at the point when the overload resolution is being done.
So based on my interepretation, according to your example using 'template struct A' above, the code is valid.
The partial ordering is not done at the definition context. But if/when you happen to invoke overload resolution
between the two functions by writing a call to f((int*)0,0) - and at that time when the compiler either
tries to assemble a candidate declaration or partially order them (if it gets to the partial-ordering step)
if an invalid expression or type results as part of the function type, SFINAE helps us out and tells
us that template deduction fails (as far as partial ordering is concerned, that implies that one
cannot be more specialized than the other if we could not even transform the template).
Now as regards POIs - if you are convinced, as I am, that the transformed function types are supposed to
represent implicit instantiations using explicitly supplied template argument lists (using the uniquely generated types)
then the following standard quotes are relevant:
14.6.4.1/1 For a function template specialization, a member function template specialization, or a specialization for a
member function or static data member of a class template, if the specialization is implicitly instantiated
because it is referenced from within another template specialization and the context from which it is referenced
depends on a template parameter, the point of instantiation of the specialization is the point of instantiation
of the enclosing specialization.
The way I interpret this is that the POI of the transformed function type and the origianl function type is the
same as the POI for those functions created by the actual function call.
litb: Since partial ordering is rather only
a property of the syntactic form of parameters (i.e "T*" against "T(*)[N]"),
i would vote for amending the specification (like "if Q appears in a nested name specifier of
a qualified-id naming a type, then the type named is "Q")
Or saying that the type named is another unique type.
This means that in template<typename T> void f(T, typename Const<T>::type*);
the argument list is (Q, R*), for example.
Same for template<typename T> void f(T*, typename ConstI<sizeof(T)>::type);
the arg lisst would be (Q*, R). A similar rule would be needed for non-type parameters, of course.
I would have to think about it and make some test cases to see if this would yield natural orderings, though.
Aah - now you are suggesting a possible solution that resolves the ambiguity in favor of what we
all intuitively expect - this is a separate problem, and while I like the direction you are heading in,
like you, I too would have to put some thought into it before proclaiming its workability.
Thanks for continuing the discussion. I wish SO didn't just limit you to placing comments.
Since you can edit my posts, please feel free to respond within the post if that is easier.