Corrado Zoccolo wrote:
On Thu, Oct 2, 2008 at 3:41 PM, Joel de Guzman <joel@boost-consulting.com>wrote:
Giovanni Piero Deretta wrote:
As I said elsewere, the extra round is hidden when lambda is used to
protect a nested expression, but it shows when used a top level:
lambda[ for_each(arg1, lambda(_a = arg2)[push_back(arg1, _a)])] () (r, i);
There is really really no need for the extra '()' there. There are no local variables in the outer lambda and even if there were, the user can initialize them with lambda(/* init here*/)[...]
Ok, this I agree.
Hmm, I think this could complicate the understanding. It seems Giovanni's complaint is because he sees lambda[] as an introducer for a lambda expression, but this is in contradiction with the fact that expressions within the lambda itself could be eagerly evaluated if not properly wrapped (and introduction of optional lazy functions could even worse the problem).
I fear an user could think that lambda[ std::cout<<"Hello world" ] is actually constructing a delayed invocation (as in C++0x), while it is not, and it cannot be.
On the other hand, if lambda[] is reserved as intended by Giovanni, what would be the syntax for creating a lazy function that returns a lazy function that returns a lazy function? We could handle differently the topmost lambda and the inner ones, but guessing the number of lambdas necessary to achieve what you want might be difficult.
For the other requests, e.g. having lazy functions that capture by reference or const reference, I think a cast like syntax could be handy: capture<by_ref>(arg1+1)
In this way, the way the arguments are captured can be changed not only at definition site, but also at call site.
Very good points. I somehow feel the same but couldn't articulate my thoughts well enough. Let's see Giovanni's answer to this one. I hope other folks would as well chime in on this crucial matter. Cheers, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net