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.

Sign up for GitHub

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

Jump to bottom

[over.match] clarify whether [over.built] and surrogate candidates are functions #3878

Open
zygoloid opened this issue Mar 17, 2020 · 1 comment
Open

[over.match] clarify whether [over.built] and surrogate candidates are functions #3878

zygoloid opened this issue Mar 17, 2020 · 1 comment
Labels
decision-required A decision of the editorial group (or the Project Editor) is required.

Comments

@zygoloid
Copy link
Member

We sometimes talk about "candidate functions", and sometimes merely about "candidates" which may or may not be functions (eg, in the definition of "viable candidate"). We should be consistent.

Either we should describe (at least) [over.built] as introducing non-function candidates or we should change the places that say "if overload resolution selects a function [...]" to say what happens if it selects a "function" from [over.built].

Similar questions apply for surrogate candidates, where there are two "functions" in scope: the real operator T function and the invented surrogate call function. We should decide whether we consider the latter to be a function or not.

Similar questions apply for rewritten candidates. Are those candidate functions or not?
@jensmaurer jensmaurer added the decision-required A decision of the editorial group (or the Project Editor) is required. label Jun 6, 2020
@jensmaurer jensmaurer changed the title clarify whether [over.built] and surrogate candidates are functions [over.match] clarify whether [over.built] and surrogate candidates are functions Jun 6, 2020
@jensmaurer
Copy link
Member

Looking at [over.match], this is a bit messy. I agree that it would be technically more correct to talk about "candidates" to be inclusive towards built-in functions, rewritten candidates, and surrogate call functions. That's a major editorial rewrite of [over.match], though, replacing (for example) "best viable function" with "best viable candidate" etc.
That said, it seems we're careful to introduce function-like declarations even for built-in and rewritten candidates so that we can meaningfully talk about a "parameter type", for example.

I can't find a lot of places where we say "if overload resolution selects X". Where the phrase appears, X is so specific (e.g. "member function" or "constructor") that the non-function options are excluded regardless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
decision-required A decision of the editorial group (or the Project Editor) is required.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@zygoloid @jensmaurer