[Bug c++/59056] ambiguous call to function template overloads not diagnosed

["walter.mascarenhas at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056

--- Comment #9 from Walter Mascarenhas <walter.mascarenhas at gmail dot com> ---
1) I just wrote that Richard's paragraph, IN ITSELF,
does not explain why things are as they are. I did not
write that there aren't other reasons to justify the
standard's decisions.

2) As I wrote, GCC does depend on the value of check< Foo<int> >()
in order to decide whether or not the code is ambiguous:
If we provide an specialization

template <> constexpr  bool check<Foo<int> >() {return false;}

then the ambiguity goes away. Of course, this specialization
changes the code and brings in other issues. I just want
to point out, naively, that the value of
check< Foo<int> >() is relevant for GCC.

3) In my naive user point of view, I believed that Richard's
observation that "the only available definition of check
always return true" would imply that

template <class X> struct  Bar<X, Enable_if< check<X>() > >{};

would be essentially equivalent to

template <class X> struct Bar<X, void>{};

and this looks less specialized than

template <> struct Bar< Foo<int>, void >{},

This was my naive view. If the standard says
otherwise then there is no point in arguing
about it.

   walter.






On Thu, Nov 14, 2013 at 1:04 AM, richard-gccbugzilla at metafoo dot co.uk <
gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
>
> --- Comment #8 from Richard Smith <richard-gccbugzilla at metafoo dot
> co.uk> ---
> (In reply to Walter Mascarenhas from comment #7)
> > In itself, Richard's paragraph "Morally, the function should
> ambiguous... "
> > implies that the code below is ambiguous. However, it
> > compiles just fine with gcc 4.8.1, because gcc also takes into
> > account the information  that check< Foo<int> >() is false
> > in order to discard the specialization with the enable_if. In
> > other words, the X in check<X> is not completely arbitrary,
> > it my be related to Foo<T>.
>
> GCC can't instantiate check<Ty> with a dependent type Ty, because that's
> not a
> meaningful thing to do. And it's not allowed to use Foo<int>, because
> partial
> ordering of templates does not depend on the actual deduced arguments for
> the
> template specialization (it orders the templates themselves, not their
> specializations). Also, the only available definition of check always
> returns
> true. So I really don't see how that could be the case.
>
> --
> You are receiving this mail because:
> You reported the bug.
>