On Thu, Nov 29, 2012 at 12:19 AM, Nathan Crookston < nathan.crookston@gmail.com> 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