-
Notifications
You must be signed in to change notification settings - Fork 771
The reference of a conversion function(template) with a deduced return type #4671
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
Comments
@jensmaurer It is a bit similar to #4811 but not completely. One is template function, the other is a function with place-holder return type. |
Agreed. The rationale for the conversion function template case is that the deduction that needs to happen here is part of name lookup. [class.member.lookup] p7 |
@jensmaurer So, I think it should be an individual issue that should be processed. After all, the deduction of a conversion function template occurs as a part of name lookup and that is deduced with the actual argument. Instead, the conversion function with the place-holder is directly deduced from its return statement. |
I'm saying the normative rule for the template case is in [class.member.lookup] p7. If you feel that's insufficient, please give more details. And fix the heading if this particular issue is not about deduced return types, but just about conversion function templates. |
@jensmaurer After further consideration, you're right. [class.member.lookup] p7 has clarified this. struct A {
template <class T> operator T*();
};
A a;
int* ip = a.operator int*();
|
In N4861, the relevant rule temp.mem#5 is:
After P1787, the above normative rule is radically changed to be a note
There's no normative rule based on to interpret why we should use
a.operator int*();
to refer to the specialization. I also feel that this issue is similar with How to explicitly call a conversion function whose conversion-type-id contains a placeholder specifier that I have posted it to wmm@edg.com, which has became the issue 2493 that will be published on http://open-std.org/jtc1/sc22/wg21/The text was updated successfully, but these errors were encountered: