[cfe-dev] A question about templates and best viable functions

[Samuele Panzeri]

Hi,

I was experimenting some code and I incurred in an unexpected error.
I reduce the code to the minimal case:

template <class T>
struct MyStruct {
operator float* () { return 0; }
operator T* () { return 0; }
};
void func(bool) {}
void func(int*) {}
int main() {
MyStruct<int> x;
func(x);
}

Compiling the previous code result in an error with both GCC and Clang
(latest version from code and 3.5 in Archlinux)

test.cpp:51:2: error: call to 'func' is ambiguous
        func(x);
        ^~~~
test.cpp:45:6: note: candidate function
void func(bool) {}
     ^
test.cpp:46:6: note: candidate function
void func(int*) {}
     ^
1 error generated.

The same error can be triggered with a template <class T> operator T* ()
and using function template argument deduction.

MSC, instead, select func(int*) in all versions from VS2010 to VS2013 CTP 3.

Now, I was wondering which one is the expected behaviour according to the
standard.
>From 13.3.3 (Best Viable Function):

— the context is an initialization by user-defined conversion (see 8.5,
13.3.1.5, and 13.3.1.6) and the
    standard conversion sequence from the return type of F1 to the
destination type (i.e., the type of the
    entity being initialized) is a better conversion sequence than the
standard conversion sequence from
    the return type of F2 to the destination type

In this case both the function call require user defined conversion.

The one using non-template parameter yield to a standard conversion
sequence of type boolean conversion (4.12).

The UDC with a template parameter should resolve in a user defined
conversion followed by a standard conversion of identity type (exact match).

Intuitively I would expect this second conversion to be considered a better
match than the latter one and be selected.

Far from being a language expert, I wonder if I'm misreading the standard
(or missing something) or if indeed this a bug in clang.

Thanks in advance for the answer,
Samuele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140909/4f70b1e7/attachment.html>