On the richness of C++

[Walter Bright]

Jason House wrote:
> For each delegate, the job variable gets captured.  Each delegate will have
> access to the job variable.  In cases of defered delegate execution,
> changes to the job variable will affect what the delegate does.
> 
> In my example, what happens if runthread is really access to a non-blocking
> thread pool that queues excess commands.  When the thread pool gets around
> to running the delegate passed in, what will be in "job"?  If this is done
> after the loop finishes, the value inside job will be the final value from
> opApply (or worse, corrupt).
> 
> The net effect is that a queue of 50 jobs may have the final job executed 50
> times, and the first 49 jobs are never run.  This does not seem like
> correct behavior to me.

This is just the usual distinction between value and reference 
semantics. D does closures by reference. If you want a value, it's 
simple enough to make a copy. I think D's method is more powerful, 
because it's a lot harder to make by-value closures into by-reference 
than the other way around.

I also believe D's method is inherently faster, because it isn't 
necessary to copy the values around (and there can be an arbitrary 
number of them, and can be arbitrarily large structs).