Checked exceptions within Block<T>

[Remi Forax]

On 01/16/2013 07:17 PM, Neal Gafter wrote:
> On Wed, Jan 16, 2013 at 2:09 AM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> 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 oracle.com <mailto:brian.goetz at oracle.com>> 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; };
>     }
>     r.run();
>
>     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.

The current lambda spec doesn't allow to capture variable, only value 
can be captured.
Anyway, I agree with your last sentence.

>
>
>     >    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".

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.

Rémi