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:43:54

On Thu, Nov 29, 2012 at 12:19 AM, Nathan Crookston <
nathan.crookston_at_[hidden]> wrote:

> Jeff,
>
> Jeffrey Lee Hellrung, Jr. wrote:
>
>> Nathan Crookston wrote:
>>>
>>> 1. Both this and Michel's suggestions require C++11 features -- either
>>> decltype or rvalue references.  Extended transformed allows the creation of
>>> a result_binder struct to be delayed until the reference type of the input
>>> range is available.  This would make it usable for non-lambda instances
>>> where an explicit return type is desired without the fuss of defining a
>>> separate functor (assuming the functor to be wrapped cannot be changed).  I
>>> believe a correct C++03 version of result_binder would need a large number
>>> of operator() overloads depending on how many arguments it intends to
>>> forward.
>>>
>>
>> True, though this sounds like more of an implementation concern (don't
>> get me wrong, it's a valid concern) than a capability concern.
>>
> Agreed.  I think there's also slightly more mental drag involved with a
> result_binder call, especially if I also need to remember where it resides
> to #include it.  But that's minor.
>

That's a legitimate point as well.

>
>  2. Such a syntax (transformed<R>(...)) has been used previously -- boost
>>> bind's docs, referring to bind<R> syntax, state:  "It is generally used
>>> with function objects that do not, or cannot, expose result_type."[1]
>>>  Without begging for an Emerson quote, I believe consistency with bind in
>>> this case will improve the usability enough to justify the required
>>> changes.  Note also that this is the only current adaptor[2] which takes a
>>> function object with arbitrary return type (others must return something
>>> which is convertible to bool).  Note also that the changes are a pure
>>> extension (previous usage continues unchanged).
>>>
>>
>> I'm personally not swayed but it's a fair rationale nonetheless and
>> ultimately your call since I'm not doing it :)
>>
> I've done all I plan to, unless a maintainer decides it's worth using and
> would like some changes.  Just to be clear, Nathan Ridge has been proposed
> as a sub-maintainer, not myself.  (FWIW, I think he's an excellent choice
> for that position.)
>

Yeah, I was confused about who was who, sorry :/

Sorry, this probably came earlier in the thread, but I suppose you have a
ticket + patch lying around somewhere? Or has a Boost.Range maintainer
agreed to implement these changes?

- Jeff