Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-03-04 00:24:02

"Jaakko Jarvi" <jajarvi_at_[hidden]> wrote in message
> On Wed, 3 Mar 2004, Jonathan Turkanis wrote:

> > >
> > > 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
> > 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.

I know about this; I was attempting a minor unification of proposed

> 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.

That was my response too, when I first saw it. Was the response to
using 'auto' as a return type more positive?

> 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
> the evaluation of the enclosing full expression anyway.

I think lambda's are rarely stored because it's hard calculate their
types. This could raise problems if yet another proposed use of auto
is accepted:

     auto x = [complex lambda expression];

> Similar problems occur if lambdas are returned from functions.

Which would be easy to do with 'auto' return types.

Looks like there are a lot of problems lurking in this neck of the


Boost list run by bdawes at, gregod at, cpdaniel at, john at