Checked exceptions within Block<T>

Neal Gafter neal at
Wed Jan 16 10:17:04 PST 2013

On Wed, Jan 16, 2013 at 2:09 AM, Remi Forax <forax at> wrote:

> On 01/16/2013 09:02 AM, Neal Gafter wrote:
> > On Tue, Jan 15, 2013 at 9:41 PM, Brian Goetz <brian.goetz at>
> wrote:
> >
> >> Dynamic detection is used, for example, to ensure that someone doesn't
> >> [...] call it after the variable to be mutated has gone out of scope.
> >>
> > You can't (syntactically) name a variable that is out of scope, so there
> is
> > no way to mutate it if it is out of scope.
> You can capture it in a lambda and call the lambda that will mutate the
> variable out of the scope.
> Runnable r;
> {
>     int a = 0;
>     r = () -> { a = 1; };
> }
> so it depends if you consider that a still exist or not when you call run.

This has nothing to do with mutation.  The lambda spec already allows
access to an (unmutated) variable after the scope in which it was declared
has completed execution, implying that captured variables have dynamic
lifetime.  Unless we were considering making that illegal (presumably with
dynamic checks), the question of whether to allow mutation has nothing to
do with variable lifetime.

> >    My point is that variable scope is a lexical concept, and lifetime is
> a dynamic concept.The variable
> > "comes in and out of scope" every time a lambda in the scope of the
> > variable is executed - and then it is in scope on some threads but not in
> > others.  It is a category error to suggest any dynamic checking would be
> > helpful.
> yes.
> lambdas that capture and mutate a local variable need at least to be
> biased to the current thread

There is no reason for such lambdas to be "biased to the current thread".

> and if you consider that accessing to
> mutating a local variable out of it scope is not legal you need another
> check.

Since you cannot name a variable that is not in scope, there is no
syntactic way to modify it.

More information about the lambda-dev mailing list