Re: g++ 2.95.2 accepts an ambiguous template overload

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> the code below compiles (and resolves to the second foo<>()) with
> g++ 2.95.2. I'm not sure that this is the correct behavior -
> specifically, I don't see that the second foo<>() is more
> specialized than the first according to the partial ordering rules.

Thanks for your bug report. I recall that you provided similar reports
in the past; however, this time, I cannot follow your logic at all.

> 1) synthesize a unique type, say U, substitute it for the template
>    parameter and perform argument deduction against the other template
>    for template <T> foo (T):
>      substitute foo(U) -> deduce foo<U>(const U&), deduced type is U, no
>      conversion required (identity conversion, 14.8.2.1, p3, bulet 1 applies)
>      hence foo<T>(T) is at least as pecialized as foo<T>(const T&)

I still have my doubts whether 14.5.5.2 really refers to 14.8.2.1 when
it mentions 

# if, and only if, the deduction succeeds and the deduced parameter
# types are an exact match

Why could this not refer to 14.8.2.3, as well? -- But I trust John
Spicer when he says that was the intent.

Even if this is true: The 'deduced parameter type' is 'const U&', the
argument type is 'U', so a qualification conversion is necessary,
i.e. it is not an exact match. The wording 'exact match' clearly
refers to conversion sequences found in overload resolution;
13.3. does not list conversion in template type arguments as an
application of overload resolution.

> I've discussed this with John Spicer of EDG who's of the opinion
> that the call is unambiguous: he doesn't think that 14.8.2.1, p3
> should be considered in step 1 above.

I agree with him.

> I also talked to HP (aCC 3.14.10 rejects the call as ambiguous) and
> they follow the same line of reasoning as myself.

You can't run through the world and convert every compiler vendor to
your interpretation of C++ :-)

> I believe that the partial ordering rules are underspecified and
> need to be clarified, however, I would appreciate your opinion
> before submitting an issue.

I definitely agree there is an issue here, I always meant to submit
one myself. Also see

http://gcc.gnu.org/ml/gcc-bugs/1999-12n/msg00337.html

I'd suggest that we draft one together - there is no point in having
two issues (IMO).

Martin