[boost] Re: parameters library and rvalue pitfall

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-11 08:09:54

Daniel Wallin <dalwan01_at_[hidden]> writes:

> David Abrahams wrote:
>> Daniel Wallin <dalwan01_at_[hidden]> writes:
>> 
>> 
>>>David Abrahams wrote:
>>>
>>>>Daniel Wallin <dalwan01_at_[hidden]> writes:
>> 
>> Done now.  I hate the name index_result, though.  I was thinking maybe
>> 
>>      parameter::binding<p, key, default>::type
>> 
>> ??
>
> Sure. Maybe we should have two, so people who want to do metaprogramming
>  doesn't have to remove_reference<>?
>
>   binding<p, key, default>::type -> T | default
>   binding_result<p, key, default>::type -> T& | default
>
> ?

I don't understand why you'd want the one without the reference
type... and -- I'm sure it's not what you want me to focus on -- but I
don't like the name "binding_result" one bit.

I'm inclined to vote "no" on this one.  It isn't a flexibility that's
known to be needed.

>>>>I think we might be able to make it a bit safer by detecting when
>>>>the default is a non-const rvalue and having p[...]
>>>
>>>Can we really detect that?
>> 
>> 
>> I'm pretty sure that for all practical purposes, we can.
>> 
>>   struct fu
>>   {
>>       template <class T>
>>       int operator|(T& x) const;
>> 
>>       template <class T>
>>       char* operator|(T) const volatile;
>>   };
>> 
>>   int a = 1;
>>   int x = fu() | a;
>>   char* y = fu() | 999;
>> 
>> Clearly you can also use a free function with enable_if to avoid the
>> volatile interaction if you really care.
>
> OK, cool.
>
>>>There's only so much we can do. This case seems hard to get wrong for
>>>the user.
>> 
>> 
>> Well I guess ultimately you want a macro (ick, in this case) with
>> decltype:
>> 
>>   binding<p, k, decltype(some_expression)>::type x = p[x | some_expression];
>> 
>> right?
>
> Ultimately I would want to write:
>
>   auto y = p[x | some_expression];
>
> and have p[...] detect rvalues and return by value when appropriate. ;)

Well, _ultimately_ p[...] can return an rvalue reference to
some_expression and avoid a copy ;-)

Anyway, I'm inclined that we not try to do this by-value return
thing.  Your thoughts?

Also:

  1. for the lazy case we should probably use result_of<F()>::type on the
     compilers that support it?

  2. We probably also need lazy_binding<p, k, f>::type, right?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com