Re: [boost] Using Boost.Function with functions that decay into function pointers

From: Darin Adler (darin_at_[hidden])
Date: 2001-09-19 11:41:06

on 9/19/01 8:57 AM, Peter Dimov at pdimov_at_[hidden] wrote:

> I'll try. 4p3 doesn't apply when e is already of type T. In this case the
> reference is bound directly to the argument (8.5.3/5.) See also
> 13.3.3.1.4/1.

I agree that binding a reference to an lvalue does not involve implicit
conversion. I thought we were talking about binding a reference to an
rvalue.

> This is still not the whole story as far as 14.5.5.2 is concerned since even
> if we accept that the deduction mimics a function call, it does not specify
> whether the synthesized argument expressions denote an lvalue or an rvalue.
> 
> I think that the intent of 14.5.5.2 is to use argument deduction as in a
> function call, with lvalues as expressions.

I agree that it must be deduction as in a function call. I think this is a
minor editorial issue, not a real ambiguity. For the other forms of
deduction there are no arguments, only argument types. But 14.5.5.2
specifically talks about synthesizing values to use as arguments. I don't
agree with the comments of the people who submitted issue 214 to the core
language issues list in sub-issue 2. Sub-issue 2 talks about using the types
directly and ignores the synthesized arguments. That seems to willfully
ignore what the standard says.

On the other hand, it doesn't seem to me that the synthesized values should
be treated as lvalues. When someone says "value of type int", it almost
almost always means an rvalue, not an lvalue, unless that is specifically
stated. Isn't that right?

If we think that:

    template<typename T> void f(const T&);
    template<typename T> void f(T*) { }

    int main()
    {
        int x = 0;
        f(&x);
    }

should unambiguously use the second function template, then I think someone
needs to raise a new core language issue about it, or add a comment to the
discussion of issue 214. But I don't think that the existing issue 214
covers it. (Nor does issue 200 or 250, for that matter.)

A sad thing about all of this is that I don't understand the issue clearly
enough to ask the CodeWarrior compiler folks to fix the problem. I had sent
in the above example and a discussion of why it should compile and run
rather than reporting an ambiguity. But I later retracted my comments.

    -- Darin