Re: [Boost-users] [Range & c++0x Lambdas] Can this be done?

Subject: Re: [Boost-users] [Range & c++0x Lambdas] Can this be done?
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2012-11-29 12:29:39

Eric Niebler wrote:
Here's the surprising part:

Jeffrey Lee Hellrung, Jr. wrote:
> > - If F::result_type exists, return F::result_type;
> > - Else:
> >    - If BOOST_NO_CXX11_DECLTYPE, return F::result< F ( Args... ) >
> >    - Else, if F::result<> exists, return F::result< F ( Args... ) >
> >    - Else return decltype( declval<F>() ( declval< Args >()... ) )
>
> The way I read this is that F::result_type (and F::result<>) is taking
> precedence over decltype. AFAICT, you're suggesting that result_of *not*
> compute the actual return type of a function object, but rather return
> the declared result type, even if it's wrong.
>
> In moving to a decltype-based result_of, we discovered just how many
> function objects in boost were lying about their return types via the
> TR1 result_of protocol. Now that we have decltype, we can get the right
> answer always. I would be *immensely* surprised if result_of ever got
> the wrong answer on a compiler that had decltype.
>

I understood the suggestion to apply when compilers had pre-3276 decltype
-- so the above wouldn't apply to latest clang, nor to other compilers once
they support incomplete types.

> And btw, I don't think lambdas are required to have a nested result_type
> typedef, are they? So what benefit does changing the protocol have?
> Wouldn't you still need a wrapper anyway?
>
 No, they're not required.  That's the heart of the issue -- if result_of
were modified (only for lacking compilers) to fall back to decltype, then
the lack of result_type wouldn't require special handling by the user.

Thanks,
Nate