[Bug c++/12536] Regression regarding partial ordering

[jhr dot walter at t-online dot de]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From jhr dot walter at t-online dot de  2003-11-01 09:15 -------
Subject: Re:  Regression regarding partial ordering

Dear Nathan,

you wrote:

> Actually, I beleive GCC is correct, but there is a DR about this
somewhere. this
> one, I think
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#214
> and #200 which points back to 214

Yes, I've noticed these defect reports (thanks to Chris Theis) and don't
fully understand the relevance of their resolution for our problem. Are
these resolutions already implemented in GCC?

> Here is my reasoning.
> 2. Overloaded bar()
>
> (i) template<typename A>
> some_type<A> bar(A const& a, A const& = A())
> (ii) template<typename R, typename A>
> some_type<R> bar(A const& a, R const& = R())
>
> [14.5.5.2]/6 tells us that the presence of unused elliopsis and
> default arguments have no effect on the partial ordering of
> function templates.

Just for the record: GCC 3.3.2 and ICC 7.1 correctly translate the example
of [14.5.5.2]/6, GCC 2.95.3 is broken.

> GCC takes that to mean that in
> partial ordering we only consider the actual parameters explicitly
> specified. Also partial ordering does not consider any explicitly
> specified template arguments.
>
> what happens is that we can take (i) and deduce against (ii), ut
> in deducing in the other direction we cannot deduce a type
> for the first template parameter (R). so (ii) is more
> specialized than (i).

When I add

template<typename A>
some_type<A> baz(A const& a, A const&);
template<typename R, typename A>
some_type<R> bar(A const& a, R const&);

to my example, all compilers agree to resolve

    baz<int>(0, 0);

to

baz<A>

and I get the desired effect of controlling overload resolution (for some
price). You've brought a strong argument that bar() should be handled like
foo().

> #214 will allow the undeduce R, as is given an explicit arg, and is
> not being used for partial ordering. Doing so will make deduction work
> in both directions and hence make the ordering ambiguous.
>
> So all the compilers a wrong!

Ouch.

Thanks for your effort,
Joerg