Re: [boost] [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

From: Eric Niebler (eric_at_[hidden])
Date: 2008-07-01 12:57:06

David Abrahams wrote:
> Eric Niebler wrote:
>> David Abrahams wrote:
>>> I don't suppose it's possible to forward lvalues and
>>> const rvalues as lvalues, and mutable rvalues as rvalues?  I haven't
>>> thought of a way, but that would be as close to "perfect" as we might
>>> expect to get in C++0x and it would be close enough for me :-)
>> We would need 2^N overloads, 
> 
> That's OK for small N

boost::function and phoenix have argument limits of 10 by default. 2^10 
is a big number. Can't wait for variadics and rvalue refs.

>> and it would be unsound because it would
>> incorrectly forward const rvalues as lvalues. 
> 
> Can you show me an example of a "sound" function that treats a const
> rvalue differently from an lvalue, please?

fusion::make_vector(), for instance. It returns a fusion::vector<> where 
the members can be held by value or by reference. Getting it wrong can 
lead to dangling references. Proto has similar function objects that 
need to be careful about the lifetime of temporaries.

>> It wouldn't be useful for
>> my purposes. What I took from the discussion about result_of and C++03
>> was that, for a function object that cares about lvalue/rvalue-ness to
>> work consistently across C++03 and C++0x, assuming rvalue-ness and
>> opting in for lvalue-ness with reference_wrapper<> is really the only
>> option. But if you have an insight, I'd be happy to reopen that
>> discussion. It was rather unsatisfying last time.
> 
> I just think that since you don't have permission to mutate a const
> rvalue anyway, forwarding it as a const reference doesn't really hurt
> anyone.

When I've gotten it wrong, it hurts.

>> <snip>
>>>> I think a wrapper like the one above that makes it easy to author
>>>> polymorphic function objects that consistently handle lvalues and
>>>> rvalues is a good first step.
>>> Great! Problem: it's not publicly available in Boost (yet)/
>> A simple, light-weight utility such as this would be very helpful, and
>> probably not too hard to get through on a fast-track review, if we could
>> just agree on semantics.
> 
> Or we could stick it in utility without review, since I'm a maintainer
> of that "library" (gotta love these loopholes!)

Sneaky.

>> If we give up on backwards compatibility, a merger is still possible. I
>> think Joel's suggestion is workable. I like the approach he and Hartmut
>> are using in the Spirit 2 transition.
> 
> Sounds like he changed his mind after all.

He did?

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com