--- In boost@[...].. , Peter Dimov <pdimov@[...]..>  wrote:
>  I think that the Lambda library should be accepted.
> 
>  * Semantics
> 
>  The two primary differences between the lambda bind and boost::bind
are:
> 
>  1. boost::bind uses mem_fn to support smart pointers:
> 
>  std::vector<boost::shared_ptr<X> > v;
>  std::for_each( v.begin(), v.end(), boost::bind(&X::f, _1) );

How will it look like with LL?

> 
>  The above unfortunately doesn't work with lambda; the bind in
lambda is not
>  a drop-in replacement for boost::bind (as I'd have liked.)
> 
>  2. Function object arity issues.
> 
>  A boost::bind expression has the same arity regardless of context,
i.e.
>  bind(&X::f, _1) always has arity [1, +inf). In lambda, the same
expression
>  has a fixed arity that is context dependent; i.e. the expression by
itself
>  has arity of 1, but in the context _2 + bind(&X::f, _1) that same
expression
>  has arity of 2.

How will it look like with LL? I.e. how to define binary function
like this:
f(x,y) = g(x,x)?

>  Bind issues aside, I my overall impression is that the library is
>  overdesigned.
>  I don't see for loops and try/catch blocks as necessary parts
>  of a lambda library; of course this is only my personal opinion,
and I am
>  free to not use the features I don't find appropriate, so this is
not a
>  major problem; it's only that this epic scope could prevent lambda
from
>  being added to the standard library. ( Another feature I don't see
a need of
>  is currying support. It seems added just because it's possible, not
because
>  it solves a practical problem. I liked the original lean-and-mean
lambda
>  from several years ago. :-) )

Second this. I can hardly imagine using of very complex function with
switch end exception handling expreseed as one expression in a
production code. What if I need to step into it in the debugger?
Though this is just my feeling, that need real usage to justify it.

[...]

>  --
>  Peter Dimov
>  Multi Media Ltd.

Regards,

Gennadiy Rozental.