"Jaakko Jarvi" <jajarvi@cs.indiana.edu> wrote in message news:Pine.LNX.4.58.0403032341250.581@eddie.osl.iu.edu...
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 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.
I know about this; I was attempting a minor unification of proposed extensions.
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 after 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 woods. Jonathan