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?
-Doug
