Checked exceptions within Block<T>

Remi Forax forax at
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 
> <mailto:forax at>> 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
>     variable.
>     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 mailing list