Re: [boost] [result_of] Test fails on clang trunk and gcc-4.7 due to changes in FDIS

Subject: Re: [boost] [result_of] Test fails on clang trunk and gcc-4.7 due to changes in FDIS
From: Michel Morin (mimomorin_at_[hidden])
Date: 2012-03-30 11:35:26

Eric Niebler wrote:
>>> Specifically, the change is about how decltype of a function call expression
>>> is determined.
>>> * N3242 says that in 7.1.6.2 p4:
>>>    if e is a function call or an invocation of an overloaded operator
>>>    (parentheses around e are ignored), decltype(e) is the return type
>>>    of the statically chosen function;
>>>
>>> * N3290 (FDIS) does not have such a wording. For a function call expression,
>>> decltype(e) is determined by the last rule in 7.1.6.2 p4:
>>>     otherwise, decltype(e) is the type of e.
>
> Right. I spoke with James Widman about this. He says the change was not
> because of the decltype v1.1 change, but rather about fixing core core
> issue 1212:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3368.html#1212

Thanks for providing the information!
I understand why the rule for xvalues is added,
but I don't understand why the rule for function calls is removed.
This removal is a breaking change...

[snip]
> James Widman also agrees with your analysis. I guess the result_of tests
> are wrong then.

To accommodate both N3290 (FDIS) decltype and pre-N3290 decltype,
we need to modify the failed tests to something like this:

    typedef const int F();

    BOOST_STATIC_ASSERT((is_same<
        remove_const<result_of<F&()>::type>::type
      , int
    >::value));

Or, should decltype-based boost::result_of emulate N3290 decltype
even on a compiler with pre-N3290 decltype?

Also, the implementation needs to be modified.
The current implementation of decltype-based boost::result_of
does not use decltype for function pointers.
So, for "typedef const int F();"
* boost::result_of<F&()>::type is int,
* boost::result_of<F*()>::type is const int,
on a compiler with N3290 decltype.

> Could you file a bug?

OK, I will file a bug later.

Regards,
Michel