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-22 14:31:05

[...rearranging...]

On Thu, Nov 22, 2012 at 6:34 AM, John M. Dlugosz <mpbecey7gu_at_[hidden]>wrote:

> Date: Wed, 21 Nov 2012 10:15:18 -0700 From: Nathan Crookston <
> nathan.crookston_at_[hidden]> To: boost-users_at_[hidden] Subject: Re:
> [Boost-users] [Range & c++0x Lambdas] Can this be done? Message-ID:
> <CAMb0s=1qtLcOiXTd5h7b2qkOSiYqjEVeN-m=rafJRHKDU6y6Cg_at_[hidden]>
> Content-Type: text/plain; charset="iso-8859-1" Rob, On Wed, Nov 21, 2012 at
> 6:39 AM, Robert Jones <robertgbjones_at_[hidden]>wrote:
>
>> Can the last line, labelled NOT Ok, be made to work? I think the lambda
>>> does
>>> not publish its result as a bind does, so I suspect it's hopeless. Any
>>> thoughts?
>>>       // NOT Ok
>>>      boost::range::push_back( out, in | transformed( []( S & s ) { return
>>> s.i; } ) );
>>> }
>>>
>>> It seems trivial to have a nested result_type in all cases with a lambda.
>>>
>> However, in C++11 there's no need for it due to decltype.
>>
>> Sadly, some compilers fall into a gap where result_of (boost or std)
>> doesn't use decltype and lambdas don't publish tr1-style result_type --
>> leaving code like the above in the lurch.
>>
>> Michel Morin wrote some code for adapting such a case which may be of
>> interest to you: http://lists.boost.org/boost-**users/2012/01/72879.php
>

>>
>> HTH,
>> Nate
>>
>
>  I had the same issue and posted it a few months ago. I wrote to the MS VS
> forum that their std::result_of should work correctly with both old and new
> formats; in particular use the declared result_type if it exists (which in
> general lets the user override the deduced type, great for compatibility
> issues).
>
> Actually doing that robustly is a bit of a maze of metaprogramming. I
> ended up making a local my_namespace::result_of that I just handles what I
> needed, and only when I asked for it. That doesn't help the existing range
> templates, but such a change could be put back into boost::result_of.
>

Maybe this is what you did, so I might not be suggesting something new,
but... Perhaps boost::result_of could have an extra conditional logic
branch added to it:
- 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 >()... ) )

Meanwhile, for different reasons, I made a macro that abstracts the
> different syntax between C++11 lambdas and Apple Block Closures. The latter
> generates a suitable lambda class complete with result_of member. That
> makes me think that you could have a macro that wraps a compiler-generated
> lambda expression in another class that inherits the operator() etc. and
> adds in the result_of typedef to simply use decltype.
>

Wouldn't that require defining a class at expression scope? Is that
possible?

- Jeff