[Bug c++/15674] New: template argument binding differs between member and static fumctions

[Bug c++/15674] New: template argument binding differs between member and static fumctions

[igodard at pacbell dot net]

#include <iostream>

int a[5];
int* p;

template<typename T>
class Foo {
public:
void S(T*) { std::cout << "found ref" << std::endl; }

template<size_t n>
void S(T(&a)[n]) { std::cout << "found array" << std::endl; }
};

template<typename T>
void S(T*) { std::cout << "found ref" << std::endl; }

template<typename T, size_t n>
void S(T(&a)[n]) { std::cout << "found array" << std::endl; }

int main() {
    Foo<int> s;
    s.S(a);
    s.S(p);
    S(a);
    S(p);
    return 0;
    }

When run, this produces:
~/ootbc/common/test/src$ a.out
found ref
found ref
found array
found ref

That is, the two calls to the member S both bind to the T* template, but for the global functions with identical signature one binds to each overload.

Ivan

-- 
           Summary: template argument binding differs between member and
                    static fumctions
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: igodard at pacbell dot net
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/15674] template argument binding differs between member and static fumctions

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-05-27 08:51 -------
I'm unsure about this kind of deduction. EDG thinks S(a) is ill-formed (two 
possible overloads), and bind the other three calls to the T* deduction. Which, 
btw, is what GCC 2.95.3 used to do.

Nathan, can you possibly have a quick look and tell us what the standard says 
about this? I tried to look it up but we all know that deduction rules are 
arcane.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nathan at gcc dot gnu dot
                   |                            |org


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

[Bug c++/15674] template argument binding differs between member and static fumctions

[nathan at gcc dot gnu dot org]

------- Additional Comments From nathan at gcc dot gnu dot org  2004-05-27 09:42 -------
This is a partial overload DR fix. John Spicer scripted DR 214 to cover
some aspects of it.  One thing he didn't fix was the ordering between
Foo (T *) and Foo (T (&)[I]).  Both deduce for an array, the former
because array->pointer decay happens before deduction when the template
argument is not a reference.

The partial ordering rules do not have that in them, so the two candidates
fail to deduce against eachother and hence are unordered.

I argue that because array->pointer decay happens at deduction, it should also
happen (when one is a ref and the other is not) at partial ordering.  That is
what I implemented in GCC when going through an early draft of 214, and
talking to John (we needed to do something, because the std was broken).

Indeed some of my own code required this partial ordering to not be ambiguous.

That the member and nonmember case behave differently is a bug in GCC.

We need to implement DR214 plus the array->pointer ordering tweak and lobby
the core committee.  It is useful to gather user input from the field as to why
this case should be ordered.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-05-27 09:42:32
               date|                            |


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

[Bug c++/15674] template argument binding differs between member and static fumctions

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2004-05-27 10:42 -------
Nathan asks for field experience, so here's what I was doing when I found the problem. 

I have a template type Row<T> that acts as a simple pointer-and-count descriptor for one dimensional slices; a poor man's valarray. It is used for non-numeric data manipulation and to provide an encapsulated package for the innumerable places where otherwise a function has to take separate pointer and count args, as you find throughout the standard libraries. I don't use valarray because that has a whole lot of numeric baggage and lacks a number of additional Row-manipulating functions that my code uses (like modulo inner-hull). I suppose I could have derived from valarray, but this is actually a port from C and I wanted to make Rows be STL-compatible containers for use with standard algorithms.

For convenience there are a number of utility constructors: () [empty]; (T*) [Row is length one and describes the poined-to element); (Row) [copy constructor]; and (T(&)[]) [Row describes entire array]. I want to be able to say:
int arr[] = {1,2,3,4,5};
Row<int> r(arr);
and wind up with r with a length of 5. If the reference to arr is turned into a pointer then it matches the T* overload and produces an array of length 1, a bug. Then to describe the whole array I'd have to write:
Row<int> r(arr, 5);
passing in the length explicitly. This would be a source of maintenance bugs every time the arr table changed in size, which in my code is frequent during development. Because this is a constructor I can't use different names to distingish the pointer from the array case, except by adding an intermediate function:
template<typename T, size_t n>
Row<T> Foo(T(&)[n]);
Row<int> r(Foo(arr));
which is clumsy.

I hope that the standard will permit an overload to match an array as distinct from a pointer, in all contexts. Sometimes you really want to know. I hope this explanation has been helpful.

Ivan

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[DR214] template argument   |template argument binding
                   |binding differs between     |differs between member and
                   |member and static fumctions |static fumctions


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

[Bug c++/15674] [3.3/3.4/3.5 Regression] [DR214] template argument binding differs between member and static fumctions

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-05-27 10:47 -------
Notice that EDG also differs in the member vs non-member case, in that the non-
member case is considered ambigous while the member case is not.

So, given Nathan analysys, the original testcase should always call the "T*" 
specialization (array->pointer decay should always happen). We have a wrong-
code bug. 2.95 used to refuse the code, so let me rate this as a regression. I 
understand that it is probably going to be minor, but nonetheless it is better 
to reject the code rather than selecting the invalid specialization.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giovannibajo at libero dot
                   |                            |it
           Severity|normal                      |critical
           Keywords|                            |wrong-code
      Known to fail|                            |2.95.3 3.0.4 3.2.3 3.3.3
                   |                            |3.4.0 3.5.0
            Summary|template argument binding   |[3.3/3.4/3.5 Regression]
                   |differs between member and  |[DR214] template argument
                   |static fumctions            |binding differs between
                   |                            |member and static fumctions
   Target Milestone|---                         |3.4.1


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

[Bug c++/15674] [3.3/3.4/3.5 Regression] [DR214] template argument binding differs between member and static fumctions

[nathan at gcc dot gnu dot org]

------- Additional Comments From nathan at gcc dot gnu dot org  2004-05-27 15:50 -------
No, my comments were that DR 214 makes both ambiguous.

However, I am strongly of the opinion that the array specialization should
be selected for the array call.

-- 


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

[Bug c++/15674] [3.3/3.4/3.5 Regression] [DR214] template argument binding differs between member and static fumctions

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-05-27 20:30 -------
OK, sorry for having misinterpreted. Then it is clearly a regression from 2.95 
as we used to do the right thing in that version (at least for the non member 
case). The member case is not a regression though.

-- 


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

[Bug c++/15674] [3.3/3.4/3.5 Regression] [DR214] template argument binding differs between member and static fumctions

[nathan at gcc dot gnu dot org]

------- Additional Comments From nathan at gcc dot gnu dot org  2004-05-28 11:57 -------
The member case is not a regression, but it is still _wrong_.
The array call should either be ambigous if we implement DR214 as it stands,
otherwise it should select the array specialization, if we allow the
array/pointer decay during partial ordering.

The non-member case is not a regression, because the 2.95 behaviour
was wrong.

-- 


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

[Bug c++/15674] [3.3/3.4/4.0 Regression] [DR214] template argument binding differs between member and static fumctions

[neroden at gcc dot gnu dot org]

------- Additional Comments From neroden at gcc dot gnu dot org  2004-11-26 23:22 -------
Nathan's conclusion was that neither case was a regression (although both were 
wrong-code bugs).  Should the "Regression" tag be removed? 

-- 


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

[Bug c++/15674] [DR214] template argument binding differs between member and static fumctions

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-12-01 18:20 -------
This is not a regression, just a bug, so I have removed the target milestone.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[3.3/3.4/4.0 Regression]    |[DR214] template argument
                   |[DR214] template argument   |binding differs between
                   |binding differs between     |member and static fumctions
                   |member and static fumctions |
   Target Milestone|4.0.0                       |---


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

[Bug c++/15674] [DR214] template argument binding differs between member and static fumctions

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


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

[Bug c++/15674] [4.0 only] [DR214] template argument binding differs between member and static fumctions

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 07:09 -------
On the mainline we reject this code:
t.cc: In function 'int main()':
t.cc:25: error: call of overloaded 'S(int [5])' is ambiguous
t.cc:16: note: candidates are: void S(T*) [with T = int]
t.cc:19: note:                 void S(T (&)[n]) [with T = int, long unsigned int n = 5ul]

Which is correct as we now implement DR 214.

Depending on PR 19203 as this only is a 4.0 bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |19203
            Summary|[DR214] template argument   |[4.0 only] [DR214] template
                   |binding differs between     |argument binding differs
                   |member and static fumctions |between member and static
                   |                            |fumctions
   Target Milestone|---                         |4.0.1


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

[Bug c++/15674] [4.0 only] [DR214] template argument binding differs between member and static fumctions

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-04-07 07:27 -------
Reporting it as ambiguous (as opposed to identifying the array) may be correct,
but I agree with Nathan that it's wrong :-)

-- 


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

[Bug c++/15674] [4.0 only] [DR214] template argument binding differs between member and static fumctions

[nathan at gcc dot gnu dot org]

-- 
Bug 15674 depends on bug 19203, which changed state.

Bug 19203 Summary: [3.4/4.0 Regression] [DR 214] Partial ordering failure between function reference and generic const reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

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

[Bug c++/15674] [4.0 only] [DR214] template argument binding differs between member and static fumctions

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-05-26 22:18 -------
I thought we long ago considered this not to be a regression.

If that's true, why is this targeted at 4.0.1?

-- 


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

[Bug c++/15674] [DR214] template argument binding differs between member and static fumctions

[nathan at gcc dot gnu dot org]

------- Additional Comments From nathan at gcc dot gnu dot org  2005-06-06 11:44 -------
Not a regression, but still a bug.  We should reject the static member case too.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |nathan at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
      Known to fail|2.95.3 3.0.4 3.2.3 3.3.3    |2.95.3 3.0.4 3.2.3 3.3.3
                   |3.4.0 4.0.0                 |3.4.0 4.0.0 4.1.0
   Last reconfirmed|2005-03-20 14:57:34         |2005-06-06 11:44:53
               date|                            |
            Summary|[4.0 only] [DR214] template |[DR214] template argument
                   |argument binding differs    |binding differs between
                   |between member and static   |member and static fumctions
                   |fumctions                   |
   Target Milestone|4.0.1                       |4.1.0


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

[Bug c++/15674] [DR214] template argument binding differs between member and static fumctions

[nathan at gcc dot gnu dot org]

------- Additional Comments From nathan at gcc dot gnu dot org  2005-06-06 12:35 -------
Closing this, it is not a bug.  What special cases the structure member example
is that one of the function is a template and the other is not.  Thus overload
resolution picks the non-template (all other things being equal).  Template
specialization ordering never gets a look in.

If you try a completely non-templated example of
  void Foo (int *);
  void Foo (int (&)[5]);
you'll discover overload resolution considers this ambiguous.  The lvalue
array->pointer transform being ignored in ranking the conversion sequences
(13.3.3.2]/3.

The case with both being template instantiations is the same wrt ranking the
conversion sequences, and template partial specialization does not get to
overrule that.

This leaves the members of S<int>, the pointer version
   void S(T *);
although it uses a template parameter, is not a template function in its own
right (it has no template header), so in the context of an instantiation of S,
it is not a template.  The other template
  template <unsigned n> void S(T (&)[n])
though, is a template in its own right, and will defer to the other function in
overload resolution.

If you want to distinguish these functions, make the pointer one a reference to
pointer in both the non-template and template cases,


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |INVALID


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