This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/9865: [3.2/3.3/3.4 regression] Template matching for reference types
- From: nathan at gcc dot gnu dot org
- To: dbeck at beckground dot hu, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nathan at gcc dot gnu dot org
- Date: 27 Mar 2003 14:01:44 -0000
- Subject: Re: c++/9865: [3.2/3.3/3.4 regression] Template matching for reference types
- Reply-to: nathan at gcc dot gnu dot org, dbeck at beckground dot hu, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nathan at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Synopsis: [3.2/3.3/3.4 regression] Template matching for reference types
State-Changed-From-To: analyzed->closed
State-Changed-By: nathan
State-Changed-When: Thu Mar 27 14:01:43 2003
State-Changed-Why:
Not a bug. It is doing exactly what the standard says.
template <typename T> struct Foo; //#1
template <typename T> struct Foo<const T>; //#2
Foo<short &> ;;// #1 or #2?
14.5.4.1/2 says a partial specialization matches if the template arguments of the partial specialization can be deduced from the actual template argument list. So, can 'const T' deduce a T from 'short &'? One deduction is that T is 'short &', which leads to a const qualified reference type. [8.3.2]/1 says that that's ill-formed *except* when
the cv qualifiers are introduced through the use of a typedef or of a template type argument, in which case they are ignored. So the partial specialization #2 is selected, rather than the primary template #1.
That is PR 2645.
DR295 was the similar case for function types, and I think it is bad for exactly the same reasons PR 9865 is giving a surprise.
To avoid the surprise, you need another partial specialization
template <typename T> struct foo<T &>;
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9865