Re: possibly a bug in g++

["Martin v. Loewis" <martin@v.loewis.de>]

> In my opinion, tfunc_t is a pointer to function, not reference. This
> is because the function name (without a context) is a pointer to
> that function, not a reference. If I am wrong, please, let me know.

You are wrong. tfunc_t is neither of type "pointer to function" nor of
type "reference to function". Instead, it is of type "function"; this
is an additional type in C and C++.

4.3, [conv.func]/1 says

# An lvalue of function type T can be converted to an rvalue of type
# pointer to T.  The result is a pointer to the function.

So you can *convert* a function type to a type pointer-to-function;
they are not the same thing. Furthermore, 5/8 says

# Whenever an lvalue expression appears as an operand of an operator
# that expects an rvalue for that operand, the lvalue-to-rvalue (4.1),
# array-to-pointer (4.2), or function-to-pointer (4.3) standard
# conversions are applied to convert the expression to an rvalue.

So when you pass a lvalue (ie. a name) in a place where an rvalue is
expected, this conversion happens automatically. This means that you
can write

        tpl_func<bool (*)(int,int)> (compare_ints);

Here, you perform an explicit argument specification, so T is not a
deduced template parameter. The resulting instantiation will have
the type

  void tpl_func<bool (*)(int, int)>(bool (*)(int, int) const&)

Since this requires a function pointer, the conversion from the
function to the function pointer is performed, and succeeds.

Likewise, if you write

        tpl_func (&compare_ints);

the argument already has the type pointer-to-function, so template
argument deduction deduces that TFunc is bool(*)(int,int). It is only
when you write

        tpl_func (compare_ints);

that TFunc becomes bool()(int,int) (which is different from
bool(&)(int,int)), so that the compiler must reject this call.

You don't have to take my word for it, please ask for confirmation in
comp.std.c++ or comp.lang.c++.moderated.

Regards,
Martin