Re: [boost] Re: Re: First lambda

From: Jaakko Jarvi (jajarvi_at_[hidden])
Date: 2004-03-04 00:03:25

On Wed, 3 Mar 2004, Jonathan Turkanis wrote:

>
> "Joel de Guzman" <joel_at_[hidden]> wrote in message
> news:4046A2AE.8020408_at_boost-consulting.com...
> > Jonathan Turkanis wrote:
> >
>
> > >
> > > How about:
> > >
> > >     unsigned long n = std::accumulate(
> > >           xs.begin(), xs.end(), 0UL,
> > >               auto(long lhs, const auto& rhs)     // inline fn
> with no
> > > name.
> > >               {
> > >                   return lhs + rhs.count;
> > >               }
> > >           );
> >
> > I would prefer also eliding the argument types:
> >
> >      unsigned long n = std::accumulate(
> >            xs.begin(), xs.end(), 0UL,
> >                lambda(lhs, rhs)
> >                {
> >                    return lhs + rhs.count;
> >                }
> >            );
> >
> > Most of the time, you also do not know the type of the
> > arguments before hand.
>
> That's why I used 'auto'. (Maybe I should have used it for the first
> argument position, too.)
>
> Isn't it useful to have a way to specify whether the argument is to be
> passed by value, reference, const reference, etc. ?

This has been brought up in the standards committee
(use of auto as a parameter type defines a template implicitly),
not for lambdas but for normal named functions.

Implicit templates would provide a fairly compact and
well defined syntax for lambdas, but the response to such implicit
templates in the standards committee was mild.

Lambdas have more serious problems to be solved first, though,
already being discussed elsewhere in this thread.
BLL lambdas are unsafe in many ways, e.g. references
to free variables can become dangling. This does not occur often in
practice, as BLL lambdas are seldom stored anywhere, and are gone after
the evaluation of the enclosing full expression anyway.
But we can encounter problems with BLL too:

int* i = new int;

*i = 1;

function<int,int> f = (*i += _1);

delete i;

f(1); // *i is gone here

Similar problems occur if lambdas are returned from functions.

The question then becomes, is this kind of unsafety acceptable for a
built-in lambda facility, or should the compiler support
closures, which would require much more than just a convenient
syntax for creating function objects on the fly.

  Jaakko