Flow scoping

Doug Lea dl at cs.oswego.edu
Sun Dec 16 15:30:44 UTC 2018

On 12/11/18 3:08 PM, Brian Goetz wrote:
> Before we get to the harder ones, can people share what made them
> uncomfortable, for the ones where you marked "not comfortable with the
> answer"?

As I hinted at in off-list response to Brian, my remaining discomfort is
that flow-scoping could be a more general language concept, and maybe
should be.

I use workarounds for lack of flow-scoping all the time in concurrent
code to statically ensure a single binding to locals (no field re-reads)
but where some of them are conditional. The way I usually do this
requires C-like declaration plus inline conditional assignment. As in
this snippet from ForkJoinPool:

            int b, k, cap; ForkJoinTask<?>[] a;
            while ((a = array) != null &&
                   (cap = a.length) > 0 &&
                   top - (b = base) > 0) {
                ForkJoinTask<?> t = (ForkJoinTask<?>)
                    QA.getAcquire(a, k = (cap - 1) & b);

Alternatives without inline assigns need more "{" scopes. Which is
almost the same problem that flow scoping for switches addresses. If
flow-scoping uniformly applied to this case (at least when using "var"),
it might instead look like:

            while ((var a = array) != null &&
                   (var cap = a.length) > 0 &&
                   top - (var b = base) > 0) {
                ForkJoinTask<?> t = (ForkJoinTask<?>)
                    QA.getAcquire(a, var k = (cap - 1) & b);

Are there other cases in which modestly expanding support for flow
scoping would help people write less-weird code?


More information about the amber-spec-experts mailing list