Checked exceptions within Block<T>
forax at univ-mlv.fr
Fri Jan 18 10:27:15 PST 2013
On 01/16/2013 10:32 PM, Neal Gafter wrote:
> On Wed, Jan 16, 2013 at 10:24 AM, Remi Forax <forax at univ-mlv.fr
> <mailto:forax at univ-mlv.fr>> wrote:
> The current lambda spec doesn't allow to capture variable, only
> value can be captured.
> The current spec allows you to use the name of a variable inside the
> lambda after the scope in which the variable was declared has exited.
> The meaning is that it gives the value last (and only, in the current
> spec) assigned to that variable. You can't "capture a value" because
> a value does not have a name. Allowing capture of mutable variables
> simply removes the parenthetical restriction in my description.
you can capture the value of the variable when you do the lambda conversion.
> There is no reason for such lambdas to be "biased to the
> current thread".
> There is a good reason, avoid to have to declare volatile local
> And if you can transfer ownership I don't see the problem.
> For the same reason, you should be able to declare instances of
> classes "biased to the current thread" so that you can "avoid to have
> to declare volatile fields". Unless you're considering that for
> classes, I don't see why you'd consider that for lambdas.
The current abstraction is fields are spaces in shared memory (the heap)
and local variable are thread local spaces (the stack). That why I think
that stack variable captured by a lambda should be thread local (that
may be promoted to shared space but explicitly).
More information about the lambda-dev