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

Subject: Re: [Boost-users] [Range & c++0x Lambdas] Can this be done?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-11-29 12:54:24

On Thu, Nov 29, 2012 at 9:46 AM, Eric Niebler <eric_at_[hidden]> wrote:

> On 11/29/2012 9:29 AM, Nathan Crookston wrote:
> > 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.
>
> Ah. Forgive me for having misunderstood the suggestion.
>
> >> 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.
>
> That's an interesting suggestion. (Thinking ...) It requires the ability
> to detect the presence or absence of a nested result<> struct template.
>

Yes.

> IIRC, this is difficult, and doesn't work on all compilers.

It's not so different from detecting the presence of result_type; hopefully
compilers with lambdas and weak decltype are sufficiently sophisticated to
handle it.

> But I could
> be mistaken.
>
> Would you be willing to open a trac ticket and attach a patch?

I can put it on the my TODO list :)

- Jeff