[Bug c++/59056] enable_if turns a non-ambiguous template into an ambiguous one

["richard-gccbugzilla at metafoo dot co.uk" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #5 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> ---
(In reply to Jonathan Wakely from comment #2)
> I thought if the partial specializations were ambiguous then these function
> overloads should be too.

Yes, this inconsistency is very surprising. GCC, EDG, and Clang all behave the
same way, and yet I can find no justification for this behavior in the
standard.

Morally, the function call should be ambiguous. The first 'func' takes Bar<X>
for any X where check<X>() is true, and the second 'func' takes Bar<X> for any
X that matches Foo<T>. Neither of those constraints implies the other, so the
call should be ambiguous.

In Clang's case, the problem is that we fail to enforce
[temp.deduct.type](14.8.2.5)/1 when partially ordering function templates -- we
don't check that deduction actually succeeded in finding types that make 'A'
match the 'deduced A' -- but we do check that when partially ordering class
templates, and we don't spot the problem earlier because the enable_if<...> is
a non-deduced context. I expect EDG and GCC have a similar bug.