You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue description: Firstly, the standard does not formally define what the length of the template-parameter-list is. This probably means the number of template-parameter.
Secondly, it is unclear what a function parameter list is. I suppose that means parameter-type-list. It is also unclear how its length is determined. This is the number of parameters only, or the ellipsis is also counted. Here and further, I omit the function parameter pack because according to CWG2942 it is proposed to remove it from the definition of parameter-type-list.
Then, in clauses (6.2.1.2.2) and (6.2.2) it is unclear what the positionally correspond for parameters mean when parameter corresponds to ellipsis. I don't see a specific clause, however, this example says that ellipsis is not a parameter, so you can think in two ways: the first, because there is no positionally corresponding parameter, their types cannot match; the second, because there is no positionally corresponding parameter, their types do not need to be checked (It's like unfolding empty packs for || and &&). But what happens if several parameters positionally correspond to ellipsis.
If their template-parameter-lists (possibly including template-parameters invented for an abbreviated function template ([dcl.fct])) contain a different number of template-parameters, or if their function parameter lists differ in lengthparameter-type-lists contain a different number of function parameters, or if exactly one of the templates contains an ellipsis, neither template is more specialized than the other.
The text was updated successfully, but these errors were encountered:
jensmaurer
changed the title
[temp.func.order] p6 Partial ordering rules don't take ellipsis into account
CWG2949 [temp.func.order] p6 Partial ordering rules don't take ellipsis into account
Nov 3, 2024
Full name of submitter: Artyom Kolpakov
Reference (section label): [temp.func.order] p6
Issue description: Firstly, the standard does not formally define what the length of the
template-parameter-list
is. This probably means the number oftemplate-parameter
.Secondly, it is unclear what a function parameter list is. I suppose that means
parameter-type-list
. It is also unclear how its length is determined. This is the number of parameters only, or the ellipsis is also counted. Here and further, I omit the function parameter pack because according to CWG2942 it is proposed to remove it from the definition of parameter-type-list.Then, in clauses (6.2.1.2.2) and (6.2.2) it is unclear what the positionally correspond for parameters mean when parameter corresponds to ellipsis. I don't see a specific clause, however, this example says that ellipsis is not a parameter, so you can think in two ways: the first, because there is no positionally corresponding parameter, their types cannot match; the second, because there is no positionally corresponding parameter, their types do not need to be checked (It's like unfolding empty packs for
||
and&&
). But what happens if several parameters positionally correspond to ellipsis.If ellipsis is not taken into account, it looks like [temp.func.order] p6 implies that
parameter-type-lists
must be the same in order to be checked against constraints. Also [over.match.best.general] p2.6 talks about the same (non-object-)parameter-type-lists (with some reservations).Suggested resolution: Edit [temp.func.order] p6.1:
The text was updated successfully, but these errors were encountered: