Design Meeting Notes, 5/12/2023

[DanielRosenwasser]

Accessor With init

tc39/proposal-decorators#508

const append = (s: string) =>
    (target, c) => {
        return {
            set(v) {
                target.set.call(this, `${v}${s}`);
            },
            init(v) {
                return `${v}${s}`;
            }
        }
    }

class C {
@append("C")
@append("B")
    accessor x = "a";
}

const obj = new C();
obj.x = "z";
console.log(obj.x);

• Logs

  cBC
  zCB
  

• Counter-intuitive - would have hoped that it was zCB for both.

• Stage 3 2023 decorators allow you to provide a replacement get, set, and init method.

  • The initializers are run in the opposite order of setters.

• Feels like existing behavior might be right?

  • Depends on your interpretation. For

    class X {
        @A
        @B
        x = C;
    }

    Do you think of A(B(x = C)), or do you think of A(B(x)) = C

• We generally support making set and init consistent based on the argument that both of the = orders should be the same.

  class C {
    @A
    @B
    x = 1;
  
    constructor() {
        x = 1;
    }
  }

Isolated Modules on Global/Script Files

#54218

• isolatedModules used to error on code that didn't have an import or export
• In 5.0, we removed the restriction and just said "you're not allowed to have things like namespaces, but you can have script code"
• But our emit changes based on isolatedModules, and this becomes more obvious if you use AMD as a module target.
• If you were using transpileModule, you never got an error anyway?
  • Actually, it does provide diagnostics - and if people didn't check their diagnostics, that's not on us.
  • Well, we're not seeing diagnostics.
    • Something in Program we're not including.
• Feels like there could be some wiggle-room for enabling the scenario in verbatimModuleSyntax if isolatedModules wasn't on.
• What we want:
  • Let's not add more isolatedModules-driven emit changes.
• We want the PR - but need to note this in the release notes

Reverting Deferral of Checking Assertion Expressions

#53879

• Removing a circularity error depended on deferring work - but that's caused a 1-2% regression.
• Seems like a band-aid, felt like it's not worth it.
• Deferring is a strategy for avoiding circularities in a lot of common cases.
• Feels like maybe there's an opportunity to more-cheaply defer the work.
• We had tried checkExpression just once - but increased time checking xstate
• Also tried checkExpressionCached - but that breaks our own codebase - but that resets CFA to avoid poisoning the cache.
• Could try to remember the expression type from NodeLinks.
• Let's try to win back the perf here.