Re: [boost] [GSoC][Phoenix3] Regarding mutability of arguments passed to phoenix expressions

Subject: Re: [boost] [GSoC][Phoenix3] Regarding mutability of arguments passed to phoenix expressions
From: Eric Niebler (eric_at_[hidden])
Date: 2010-06-11 12:12:27

On 6/11/2010 11:49 AM, David Abrahams wrote:
> At Fri, 11 Jun 2010 11:12:46 -0400,
> Eric Niebler wrote:
>>
>>> We now have lambdas in C++0x. IMO, we should be paying attention to 
>>> the default semantics of lambdas which, IIRC, accept their arguments
>>>  by value(?), and have special syntax for accepting their arguments
>>> by reference. Someone should correct me if I got that backwards. In
>>> the long haul, I think this will satisfy the Principle of Least 
>>> Surprise.
>>
>> Following up on this ... I was conflating lambda arguments with captured
>> variables that appear in the lambda body. I just looked over the draft
>> standard, and variables are captured by reference by default and need
>> special syntax to capture them by value. 5.1.2/14-15:
> 
> I don't see how you draw that conclusion from the text below.

I went back, and you're right. 5.1.2/11-12 make it clear that implicit
capture happens only when a default capture mode is specified. Good.

That gives us an opportunity to add a new feature to Phoenix: default
capture modes. I could see something like:

  ref[ phoenix-lambda-expression ]

makes default capture by-ref, and

  val[ phoenix-lambda-expression ]

makes it by-val. Under the hood, Phoenix would actually be storing every
captured variable both by value and by reference. ref and val simply
change how the resulting tree is interpreted. In addition, we can let
users pick and choose on a per-variable basis using the the ref(x) and
val(x) on every use of the variable x within the expression.

>> As for the lambda arguments, Phoenix can take no guidance from the
>> standard since the built-in lambdas require you to define an argument
>> list, making them monomorphic. We could aim for consistency with the
>> capture behavior and pass by reference, or be consistent with std::bind
>> which uses rvalue refs and perfect forwarding (darn), or TR1 bind and
>> boost::bind which accepts parameters by value.
>>
>> Given the choices, I think pass-by-value makes the most sense.
> 
> why not perfect forwarding?

Because it's too expensive to simulate in C++98.

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