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

Subject: Re: [Boost-users] [Range & c++0x Lambdas] Can this be done?
From: Neil Groves (neil_at_[hidden])
Date: 2012-11-22 04:20:04

On Wed, Nov 21, 2012 at 9:26 PM, Eric Niebler <eric_at_[hidden]> wrote:

> On 11/21/2012 11:27 AM, Nathan Ridge wrote:
> >
> >> On Wed, Nov 21, 2012 at 5:15 PM, Nathan Crookston
> >> <nathan.crookston_at_[hidden]<mailto:nathan.crookston_at_[hidden]>> wrote:
> >> Rob,
> >>
> >> On Wed, Nov 21, 2012 at 6:39 AM, Robert Jones
> >> <robertgbjones_at_[hidden]<mailto: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.
> >>
> >> - Rob.
> >
> > I've been turning on BOOST_RESULT_OF_USE_DECLTYPE for such occasions
> > and haven't had any problems with it.
>
> It's *mostly* safe on *most* modern compilers to do that. Boost has been
> very cautious about rolling out its decltype-based result_of
> implementation because "mostly" doesn't cut it. But starting with 1.52,
> it's enabled by default on clang 3.1 and higher. More compilers will be
> added as their decltype support improves.
>
>
I've definitely considered this issue in the context of Boost.Range and
have as yet failed to come up with anything that works well enough without
problems. I need to spend some time looking at the Michel Morin
contribution.

I do not intend releasing a change to Boost.Range that allows code to
compile that has edge cases that are easy to fall into that cause major
problems. In practice it might be necessary to conditionally enable this
feature for a subset of the supported compilers. I am totally convinced of
the additional values that Boost.Range interoperation with lambdas provides
and this is therefore worth lots of effort.

In the interim solution proposals are very welcome. It could well be that I
haven't thought of something simple that is generally safe.

> --
> Eric Niebler
> BoostPro Computing
> http://www.boostpro.com
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>

Thanks,
Neil Groves