Re: koenig lookup in C++

[Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>]

> After looking at the C standard, I think that
> g++.old-deja/g++.ns/koenig7.C is legal C++, and so this patch must be
> wrong:
> 
> 2000-08-11  Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr>
> 
> 	* decl2.c (add_function): Reorganize.
> 	(arg_assoc): Do not consider function template decls.
> 
> A simplified verson of the test looks like this:
> 
> namespace N1 {
>   struct A { };
>   void f2(float) {}
>   void g(void (*)(float)) {}
> }
> 
> using N1::f2;
> template <class T>
> void f2(N1::A, T) {}
> 
> void g(void (*)(int)) {}
> 
> int main() {  
>    g(f2); // Works?
> }
> 
> I believe this should work, because the argument
> types of the g(f2) function are:
> 
> void f2(float)
> template <class T> void f2(N1::A, T)
> 
> both of these are function types.  For function types, the associated
> namespaces are those associated with their parameter and return
> types.  For the first function type, there are no associated
> types as all the parameters/return values are fundamental types.  For
> the second set of function types, namespace N1 is associated because
> one of the parameters is of type N1::A, a structure type in N1, which
> has N1 associated with it.
> 
> Thus g can be either the g in the default namespace or the g in N1;
> and then the only one that matches is the g in N1, and the parameter
> must be N1::f2.
> 
> Does this sound right?  I'm no C++ language lawyer, I just play one on
> TV :-). 

Well, I'm not a C++ language lawyer either (just a poor user that 
sometimes needs to go and have a look to the standard :-) ).
But here I'm quite sure that it is the test case that is wrong:

  Your templated f2 function certainly cannot be associated with any g 
  function as it takes 2 parameters whereas all g functions expect as a 
  parameter a function with ONLY ONE argument.

Thus as proposed by Nathan and Kriang (but for a different reason),
the following patch should be applied.

Index: koenig7.C
===================================================================
RCS file: /cvs/gcc/egcs/gcc/testsuite/g++.old-deja/g++.ns/koenig7.C,v
retrieving revision 1.2
diff -c -3 -p -r1.2 koenig7.C
*** koenig7.C   1998/12/16 21:50:33     1.2
--- koenig7.C   2000/08/16 16:32:19
*************** void g(void (*)(int)) {}
*** 18,22 ****
  
  int main() {  
     g(&f1); // Works?
!    g(f2); // Works?
  }
--- 18,22 ----
  
  int main() {  
     g(&f1); // Works?
!    g(f2);  // ERROR - cannot convert
  }

Then, this being said I must say that I'm no longer so sure (I was 
when I created the patch, but cannot convince myself anymore) of why
only instanciated function templates must be used for Koenig lookup
(This is the hing Mark gave to me). The only line of reasonning that
supports this claim (that I can find) is that the template-name of the function template
might not be used as a function pointer thus the function
type rule in 3.4.2 cannot be used and instead the template-id rule
(also in 3.4.2) must be used (ie you should write g(f2<int>) instead of g(f2)).
Indeed, I'll hate if the compiler had a different behaviour for the two cases g(f2)
and g(f2<int>). Is this the right reasonning ?

Now the question is whether g(f2) (with f2 being a function template) should be allowed at
all? With the above reasonning, it seems to me that no, it should not 
so that we should add a message which:

	- should be an error when all the candidates are template functions names.
        - should be a warning when there is at least one regular 
          function f2.

Is this sounds right ?? If yes then I'll do a patch to issue 
a warning/error.

> If so, I'd appreciate it if someone could either (a) revert
> the patch, (b) fix it, or (c) mark the testcase as XFAIL.  Otherwise
> the testcase is wrong, which should be easy enough to fix.

Unfortunately, I cannot do much in this respect (just propose patches).
I think that the above explanations rules out (a) and (c) and pushes 
toward the stupid patch for the otherwise clause of your demand.

	Sorry to have created this (fake?) regression...

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------