Stage 3 feedback: can we make the number of using decls that need disposal statically knowable?

[syg]

During implementation we realized the following cursed code is possible:

switch (lbl) {
  case 0:
    using x = init();
    break;
}

AFAIK other than this, declarations aren't conditionally evaluated inside a scope. This weirdness means that you have to check at runtime whether a binding actually has a disposable resource. It'd be nice if all using bindings are unconditionally disposed at scope exit.

While I appreciate that other binding forms are allowed in bare switch cases like that and changing this would break symmetry, using declarations already break symmetry elsewhere. Is there a reason to allow this pattern?

[rbuckton]

AFAIK other than this, declarations aren't conditionally evaluated inside a scope. This weirdness means that you have to check at runtime whether a binding actually has a disposable resource. It'd be nice if all using bindings are unconditionally disposed at scope exit.

How does this differ from other cases where only initialized bindings are disposed? i.e.:

outer: {
  if (y) break outer;
  using x = init();
} // 'x' isn't disposed if 'condition' was true

for (const y of ar) {
  if (y) continue; // possible early continue before `using`
  using x = init();
}

You have to check at runtime whether the resource is disposable when it is initialized, since you also have to capture the @@dispose method at that time as well. If lbl is something other than 0 in your exmaple, or if y is true in my example, init() is not evaluated and thus x is not initialized and the resource and its @@dispose aren't captured. Not to mention if you have:

{
  using x = init1();
  using y = init2();
}

and init1() throws before y is initialized.

[syg]

Good points! You are right, there are many cases that require runtime tracking of disposable resources in using declarations. The last example is particularly compelling.

I mostly retract this complaint on the basis my original argument was wrong.

But I do think there's something to be said about programmer intent. The conditional initializations in your examples seem to say that absent some exceptional cases, the scope intends to dispose all its using bindings. Having using declarations in bare switch cases just seems always like a mistake: the programmer most likely mistakenly thought that each case has its own block scope.

[rbuckton]

Having using declarations in bare switch cases just seems always like a mistake: the programmer most likely mistakenly thought that each case has its own block scope.

I'd prefer to remain consistent with let and const here, otherwise scoping rules go completely out the window and resource lifetime no longer matches scope:

let x = 0;
switch (x) {
  case 0:
    const a = 1;
    // falls through
  case 1:
    const b = { value: 2 };
    // falls through
  case 2:
    if (x === 0) console.log(a);
    if (x === 0 || x === 1) console.log(b.value);
}

this prints:

1
2

thus I would expect the following to be the same:

let x = 0;
switch (x) {
  case 0:
    const a = 1;
    // falls through
  case 1:
    using b = { value: 2, [Symbol.dispose]() { } };
    // falls through
  case 2:
    if (x === 0) console.log(a);
    if (x === 0 || x === 1) console.log(b.value);
}

Deviating from that would both break developer intuition based on prior experience with let and const and would not align with the lifetime requirements for using.

I also wouldn't necessarily consider such code to be a mistake as switch cases and fall-through can be beneficial to efficient algorithms that use loop unrolling for performance. If using in a switch case seems like code smell, I'd argue that's what lint rules are for. If a linter enforces a no-using-in-bare-switch-case rule, an experienced developer could override that rule as necessary to write an efficient algorithm. If the language enforces that rule, the experienced developer is at a disadvantage as they must also unroll the disposal algorithm.

As it stands, most linters already enforce a no-fallthrough rule that already addresses that case.

[syg]

thus I would expect the following to be the same:

I would still like the second code snippet to throw a SyntaxError. I don't agree with the claim "otherwise scoping rules go completely out the window and resource lifetime no longer matches scope", because I don't feel that developers, even those with deep spec knowledge, have a consistent model for what the scope for lexical declarations inside switch cases is. Having a static error for a problematic case doesn't reach the level of "scoping rules go completely out the window" to me. I don't think using should do something different in switch cases, but prohibited.

Also, using is already special in other syntactic ways, like disallowing destructuring.

I also wouldn't necessarily consider such code to be a mistake as switch cases and fall-through can be beneficial to efficient algorithms that use loop unrolling for performance.

I have my doubts that using in a bare switch case leads to efficient algorithms. Do you have an example (even a toy one) in mind?

Re-thinking #215 (comment), the difference between control flow like continue and break and using in switch cases is that continue and break can still be statically compiled a fully unrolled dispose loop.

For example,

{
  using a = foo();
  if (cond1) break;
  using b = foo();
  if (cond2) break;
}

can still be compiled to avoid the generic dispose loop. In the following pseudocode, assume bindings with a leading . are internal, that gotos exist, and I've also handwaved away how exceptions are done (the range of code that threw is mapped to L2, L1, etc):

.a_disposable_rsrc = undefined;
.b_disposable_rsrc = undefined
come_from_label = undefined;
try {
  const a = foo();
  .a_disposable_rsrc = GetDisposableResource(a);
  if (cond1) goto L1;
  const b = foo();
  .b_disposable_rsrc = GetDisposableResource(b);
  if (cond2) goto L2;
  goto L_All;
} finally {
  L_All:
  L2: Dispose(.b_disposable_rsrc);
  L1: Dispose(.a_disposable_rsrc);
}

AFAICT the only place where we can't unroll the dispose loop is if a using is present in a switch case. It'd still be nice to not have that if there're no real use cases.

[iainireland]

I second Shu's point.

In every case except switch, I believe that you can effectively desugar a using statement to something resembling a try-finally.

For example,

for (const y of ar) {
  if (y) continue; // possible early continue before `using`
  using x = init();
  <body>
}

becomes

for (const y of ar) {
  if (y) continue;
  let x = init();
  let x_dispose = GetDisposable(x);
  try {
    <body>
  } finally {
    Dispose(x_dispose);
  }
}

And Shu's example with two using declarations:

{
  using a = foo();
  if (cond1) break;
  using b = foo();
  if (cond2) break;
}

is equivalent to:

let a = foo();
let a_dispose = GetDisposable(a);
try {
  if (cond1) break;
  let b = foo();
  let b_dispose = GetDisposable(b);
  try {
    if (cond2) break;
  } finally {
    dispose(b_dispose);
  }
} finally {
  dispose(a_dispose);
}

The same is not true in a switch statement, because it would effectively require you to jump into the middle of a try block. If I'm not mistaken, this is the only case where disposal scheduling can't be done statically (modulo null/undefined, where disposal is trivial).

Note that the same problem does not occur in cases like this:

switch (lbl) {
  case 0: {
    using x = init();
    ...
    break;
    // disposal happens here
  }
  case 1:
    ...
}

It's specifically bare switch cases that are a problem. I'm strongly in favour of forbidding them.

[ljharb]

Why can't

switch (lbl) {
  case 0: {
    using x = init();
    ...
    break;
    // disposal happens here
  }
  case 1:
    ...
}

be desugared into:

switch (lbl) {
  case 0: { try {
    let x = init();
    let x_dispose = GetDisposable(x);
    ...
    break;
    } finally {
    dispose(x_dispose);
    }
  }
  case 1:
    ...
}

?

[syg]

Why can't

You can if the case bodies have their own blocks. We're complaining about bare case bodies.

[ljharb]

ahhh, gotcha - because adding a block would conflict with let/const declarations.

[iainireland]

To be clear, the case that I would like to prohibit is this one that Ron posted:

let x = 0;
switch (x) {
  case 0:
    const a = 1;
    // falls through
  case 1:
    using b = { value: 2, [Symbol.dispose]() { } };
    // falls through
  case 2:
    if (x === 0) console.log(a);
    if (x === 0 || x === 1) console.log(b.value);
}

[ljharb]

in that case, you can't wrap the entire switch statement, and do all the relevant disposals there?

[iainireland]

Not easily.

It would mean that while parsing, if you see a using inside a switch, you'd effectively have to go back in time to the beginning of the switch to retroactively insert the new scope.

[dminor]

@rbuckton Would you be willing to take this issue to committee at an upcoming plenary? There's feedback here from two separate implementations that prohibiting using inside bare switch case statements would at the very least simplify implementations and probably also lead to something more efficiently implementable. I think this would be worth discussing.

[rbuckton]

Would you be willing to take this issue to committee at an upcoming plenary? ...

I can, yes, but likely not next week's plenary.

In every case except switch, I believe that you can effectively desugar a using statement to something resembling a try-finally.

[...]

The same is not true in a switch statement, because it would effectively require you to jump into the middle of a try block.

The approach we take in TypeScript's downlevel emit is to wrap the switch in a try block.

given:

let x = 0;
switch (x) {
  case 0:
    const a = 1;
    // falls through
  case 1:
    using b = { value: 2, [Symbol.dispose]() { } };
    // falls through
  case 2:
    if (x === 0) console.log(a);
    if (x === 0 || x === 1) console.log(b.value);
}

we produce:

let x = 0;
const env_1 = { stack: [], error: void 0, hasError: false };
try {
    switch (x) {
        case 0:
            const a = 1;
        // falls through
        case 1:
            const b = __addDisposableResource(env_1, { value: 2, [Symbol.dispose]() { } }, false);
        // falls through
        case 2:
            if (x === 0)
                console.log(a);
            if (x === 0 || x === 1)
                console.log(b.value);
    }
}
catch (e_1) {
    env_1.error = e_1;
    env_1.hasError = true;
}
finally {
    __disposeResources(env_1);
}

So yes, we do need to adjust the scope of the switch to accomplish this.

If I'm not mistaken, this is the only case where disposal scheduling can't be done statically (modulo null/undefined, where disposal is trivial).

What do you mean by "can't be done statically"? Are you referring to being able to limit the scope to case 1 and case 2? Per the proposal text, the disposal scope would cover the entire CaseBlock.

@syg notes that cases like

{
  using a = foo();
  if (cond1) break;
  using b = foo();
  if (cond2) break;
}

can still be statically unrolled, yet I don't see why switch could not do the same. Given:

switch (x) {
  case 0:
    using a = foo();
    if (cond1) break;
    // falls through
  case 1:
    using b = foo();
    if (cond2) break;
}

you might expect something like (given the above pseudocode):

.tmp = x
.a_disposable_rsrc = undefined;
.b_disposable_rsrc = undefined;
try {
  switch(.tmp) {
    case 0: 
      const a = foo();
      .a_disposable_rsrc = GetDisposableResource(a);
      if (cond1) goto L1;
    case 1:
      const b = foo()
      .b_disposable_rsrc = GetDisposableResource(a);
      if (cond2) goto L2;
  }
  goto L_All;
} finally {
L_All:
  Dispose(.b_disposable_rsrc)
  Dispose(.a_disposable_rsrc)
}

or even further reduced:

.tmp = x
.a_disposable_rsrc = undefined;
.b_disposable_rsrc = undefined;
try {
  if (.tmp === 0) goto L_Case0; // case 0:
  if (.tmp === 1) goto L_Case1; // case 1: 
  goto L_End;

L_Case0:
  const a = foo();
  .a_disposable_rsrc = GetDisposableResource(a);
  if (cond1) goto L1;

L_Case1:
  const b = foo()
  .b_disposable_rsrc = GetDisposableResource(a);
  if (cond2) goto L2;
  goto L_All;

} finally {
L_All:
L2:
  Dispose(.b_disposable_rsrc)
L1:
  Dispose(.a_disposable_rsrc)
L_End:
}

[syg]

Still a lot of work for a use case nobody has and should be linted against.

[iainireland]

What do you mean by "can't be done statically"? Are you referring to being able to limit the scope to case 1 and case 2? Per the proposal text, the disposal scope would cover the entire CaseBlock.

The spec for explicit resource management is written in terms of a disposeCapability containing a list of resources to be disposed. Our current implementation reifies that list as a real object that is dynamically tracking the disposables. There's an alternative, more efficient implementation where we generate a synthetic finally for each using. But the switch case can't be expressed that way. You can't start a try block inside one branch of a case, and finish it in another one. That's true both at the level of syntax, and in terms of how the semantics of try and switch are implemented inside an engine.

Your pseudocode only works because you've hoisted the scope of the try outside the switch statement. As I already mentioned, that's not easy in a high-performance parser. It requires multiple passes over the body of the switch, which we make a concerted effort to avoid.

If all this work was critically necessary to support an important feature, that would be one thing. But this code pattern is terrible, and nobody should ever write it.

tl;dr: Shu++