Re: [boost] Giving names to formal parameters of lambda expressions: a named placeholder trick.

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-03-30 17:55:47

On Sun, Mar 30, 2008 at 11:28 PM, David Abrahams
<dave_at_[hidden]> wrote:
>
>  on Fri Mar 28 2008, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
>
>  > AMDG
>  >
>  > Giovanni Piero Deretta wrote:
>  >> That is, something like this is actually possible:
>  >>
>  >>   void foo  () {
>  >>     int i =
>  >>      lambda
>  >>       // introduce formal parameter names
>  >>       [  _<class left>(),
>  >>          _<class right>()
>  >>       ]
>  >>       // now use them!
>  >>       [_<left>() + _<right>()]
>  >>       // actual parameters values
>  >>      ( 10,  20 );
>  >>   }
>  >>
>  >> The _<...>() looks a bit clumsy, but it might be actually usable.
>  >>
>  >
>  > I'd rather not use _.  arg sound better.
>  > lambda<class left, class right>(arg<left>() + arg<right>())
>
>   lambda<args(class left, class right)>(arg<left>() + arg<right>())
>
>  I actually like the short nondescriptive names.  It's very rare that the
>  semantic information in a descriptive name is more valuable than the
>  syntactic economy of the existing syntax.  Just compare the above to:
>
>   _1 + _2.
>
>  Which do you find clearer?

For simple expressions I agree 100%.

>  When the lambda expression is complicated
>  enough that having real names is actually a win, I am usually inclined
>  to write a separate, named function (object), anyway.

For boost lambda I somewhat agree. Complex expressions unfortunately
become too compile time heavy.
OTOH,  refactoring a lambda on a separate function object is a pain if
you have to figure out the result of a complex composition
of polymorphic function objects (result_of helps only to a point). For
example, what is the result of:

filter_view(reverse_view(mapped_view(range, op)), filter)

(I often find much more complex expressions in my code).

Also,what about MPL? As it deals only with types, the named parameter
syntax is very light,
and I have found out that one can write very complex mpl expressions
with very little need for refactoring.

>
>  > Wow.  This is awesome.  You'd probably better reference the standard
>  > (3.3.1/5) since most people will look at this and be surprised to find
>  > that it's legal.  (I certainly was)
>
>  Not so fast.  It's legal outside a function, but inside a function
>
>     "class A"
>
>  refers to a local class of the function, which isn't a legal template
>  parameter.  You might try the following at
>  http://www.comeaucomputing.com/tryitout/
> [...]

I did (see my other message). Yes, unfortunately the trick is illegal
at function scope at lest untill C++0x.
Which limits a lot its usefulness.

-- 
gpd