[Voted into WP at October 2003 meeting.]

Proposed resolution (October 2002):

In 13.4 add to the end of paragraph 2:

[Note: As described in 13.10.2 [temp.arg.explicit], if deduction fails and the function template name is followed by an explicit template argument list, the template-id is then examined to see whether it identifies a single function template specialization. If it does, the template-id is considered to be an lvalue for that function template specialization. The target type is not used in that determination.]

In 13.10.2 [temp.arg.explicit] paragraph 2 insert before the first example:

In contexts where deduction is done and fails, or in contexts where deduction is not done, if a template argument list is specified and it, along with any default template arguments, identifies a single function template specialization, then the template-id is an lvalue for the function template specialization.

Change the first example of 13.10.2 [temp.arg.explicit] paragraph 2:

  template<class X, class Y> X f(Y);
  void g()
  {
    int i = f<int>(5.6);    // Y is deduced to be double
    int j = f(5.6);         // ill-formed: X cannot be deduced
  }

  template<class X, class Y> X f(Y);
  void g()
  {
    int i = f<int>(5.6);    // Y is deduced to be double
    int j = f(5.6);         // ill-formed: X cannot be deduced
    f<void>(f<int, bool>);  // Y for outer f deduced to be
                            //   int (*)(bool)
    f<void>(f<int>);        // ill-formed: f<int> does not denote a
                            //   single template function specialization
  }

Note: This interacts with the resolution of issue 226 (default template arguments for function templates).

Notes from 04/01 meeting:

The consensus of the group was that the add example should not be an error.

    template <class T> void f(T);
    template <class T> void g(T);
    template <class T> void g(T,T);

    int main()
    {
        (&f<int>);
        (&g<int>);
    }

12.3 [over.over] paragraph 1 says that a function template name is considered to name a set of overloaded functions. I believe it should be expanded to say that a function template name with an explicit template argument list is also considered to name a set of overloaded functions.

In the general case, you need to have a destination type in order to identify a unique function. While it is possible to permit this, I don't think it is a good idea because such code depends on there only being one template of that name that is visible.

The EDG front end issues an error on this use of "f". egcs 1.1.1 allows it, but the most current snapshot of egcs that I have also issues an error on it.

It has been pointed out that when dealing with nontemplates, the rules for taking the address of a single function differ from the rules for an overload set, but this asymmetry is needed for C compatibility. This need does not exist for the template case.

My feeling is that a general rule is better than a general rule plus an exception. The general rule is that you need a destination type to be sure that the operation will succeed. The exception is when there is only one template in the set and only then when you provide values for all of the template arguments.

It is true that in some cases you can provide a shorthand, but only if you encourage a fragile coding style (that will cause programs to break when additional templates are added).

I think the standard needs to specify one way or the other how this case should be handled. My recommendation would be that it is ill-formed.

Nico Josuttis: Consider the following example:

    template <int VAL>
    int add (int elem)
    {
	return elem + VAL;
    }

    std::transform(coll.begin(), coll.end(),
		   coll.begin(),
		   add<10>);

If John's recommendation is adopted, this code will become ill-formed. I bet there will be a lot of explanation for users necessary why this fails and that they have to change add<10> to something like (int (*)(int))add<10>.

This example code is probably common practice because this use of the STL is typical and is accepted in many current implementations. I strongly urge that this issue be resolved in favor of keeping this code valid.

Bill Gibbons: I find this rather surprising. Shouldn't a template-id which specifies all of the template arguments be treated like a declaration-only explicit instantiation, producing a set of ordinary function declarations? And when that set happens to contain only one function, shouldn't the example code work?

(See also issue 250.)