Documenting/Notes on overload resolution behaviour #7218
realvictorprm
started this conversation in
General
Replies: 1 comment
-
It shouldn't be that complicated to get a detailed spec. To me it sounds like delayed resolution should happen when there are 2 or more candidates with the same "score". This means, that overload resolution ambiguity errors should never occur (unless the function is not inline). If there is ambiguity => delay it. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
After a talk with Phillip Carter I'll try to document the current overload resolution behaviour here. People with deep knowledge about this (especially you @dsyme!) comment if you can add information to unclear parts & also please comment if specific parts of this are wrong.
Open questions and notes about overload resolution
Starting at
14.5.4 Solving Member Constraints
:This leaves interpretation open for the implementation if multiple overloads would be a fit for the current constraint (did not find a section about how multiple fitting overloads should be handled).
Behaviour on multiple fitting overloads:
To my understanding of the code in the compiler, behaviour with multiple overloads is following.
free
/ specific resolved types.The delayed overload resolution isn't well enough documented for me to get a full crasp of what is expected to happen (which may be a reason why there are bugs in there afterall).
This hole in specification and documentation allows one to abuse the current implemented mechanism in such ways that:
Beta Was this translation helpful? Give feedback.
All reactions