Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Partial ordering rules for packs in [temp.deduct.type] #4014

Open
sdkrystian opened this issue May 24, 2020 · 9 comments
Open

Partial ordering rules for packs in [temp.deduct.type] #4014

sdkrystian opened this issue May 24, 2020 · 9 comments
Labels
cwg Issue must be reviewed by CWG. decision-required A decision of the editorial group (or the Project Editor) is required.

Comments

@sdkrystian
Copy link
Contributor

The wording in [temp.deduct.type] p10 that effectively states "during partial ordering, a function parameter pack is less specialized than N matching function parameters" doesn't apply to partial ordering the the context of a function call, since rather than using the entire function type for deduction, only the types of the parameter with arguments in the call are used, meaning that P does not have a form that contains (T) unless the type of the parameter itself was compounded from a function type.

@jensmaurer
Copy link
Member

It is correct that the original template argument deduction for function calls is on a per-parameter/argument basis. Using the thus-deduced template parameters, a specialization (of the declaration) is generated which is then used as the input for further overload resolution, which may consider partial ordering as a tie-breaker for the entire candidate (= specialization of the function template declaration). At that point, the entire declaration is in view, and [temp.func.order] p2 says the "function type" is used for partial ordering.

@sdkrystian
Copy link
Contributor Author

@jensmaurer Hm, are you sure? http://eel.is/c++draft/temp.deduct.partial#3 says that the deduction for partial ordering is done on a per parameter/argument basis in the context of a function call

@jensmaurer
Copy link
Member

jensmaurer commented May 25, 2020

Good point. However, this doesn't seem to be an editorial issue.

@jensmaurer jensmaurer reopened this May 25, 2020
@jensmaurer jensmaurer added the cwg Issue must be reviewed by CWG. label May 25, 2020
@jensmaurer
Copy link
Member

jensmaurer commented May 25, 2020

The example given at the end of temp.deduct.type p10 is a non-call context, though, where the rule does apply as specified. So, where exactly is the editorial problem?

@sdkrystian
Copy link
Contributor Author

sdkrystian commented May 26, 2020

@jensmaurer The problem itself would arise in the following example:

template<typename T>
int f(T); // #1

template<typename... T>
int f(T...); // #2

int a = f(1); // calls #1

Our intent here is that #1 is called, as shown in the example in [temp.deduct.partial] p8. The partial ordering here is done in the context of a function call, so the deduction is done with respect to the individual parameters and arguments, and consequently the rule that would cause deduction to fail in [temp.deduct.type] p10 (which would make the non-pack parameter at least as specialized as the pack parameter, but not the other way around) doesn't apply.

As for the editorial nature of this issue, that example pretty clearly demonstrates what we want to happen. CWG has also stated what we want to happen in CWG 1825 and CWG 1395.

@jensmaurer
Copy link
Member

[temp.deduct.partial] p3 says that we use individual parameters, but then [temp.deduct.partial] p8 has special rules for variadic templates, and look beyond the individual parameter's P/A pair.
The example at the end of p8 is (essentially) the one you quoted above.

@sdkrystian
Copy link
Contributor Author

but then [temp.deduct.partial] p8 has special rules for variadic templates, and look beyond the individual parameter's P/A pair.

Yup, it effectively says we "look ahead" to match trailing packs. However, it still doesn't use the entire function type, so [temp.deduct.type] p10 wouldn't apply.

@jensmaurer
Copy link
Member

My assumption is that we don't need/want [temp.deduct.type] p10 to apply for this case, since we already have similar wording in [temp.deduct.partial] p8 for matching variadics.

@sdkrystian
Copy link
Contributor Author

The wording in p8 doesn't cause the deduction to fail (as we intend it to) meaning that it would have no effect on the example I provided.

@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Jun 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cwg Issue must be reviewed by CWG. decision-required A decision of the editorial group (or the Project Editor) is required.
Projects
None yet
Development

No branches or pull requests

2 participants