Arrow Function and Conditional Type Parsing

#48733 (comment)

• We changed the way we parse conditional expressions and arrow functions because of TypeScript type annotations.
• We have a few workarounds, but it's too close to the release to do these changes.
• So the idea is to revert temporarily.
• Seems uncontroversial to revert - just which will we pick?
• 3 options
  • Permissive: any TypeScript code that parsed before still works.
    • Try parsing an entire arrow function, see that there's not a colon, toss the old arrow function away.
  • Strict:
  • Strictest: Just explicitly break the ambiguity. You have to put parentheses.
• We're trying to ensure we parse JS correctly so we can figure out how the type annotations proposal can mesh well here.
• Cases where TS prefers the type interpretation rather than the actual JS interpretation.
  • Maybe fine, but we should parse JS as JS.
• What are the operating principles?
  • Don't break existing code in TS.
    • Divergences which are unfortunate, but it's where we are.
  • Ensure valid JS parses correctly.
  • We should then make existing errors in TS which would have succeed in JS parse correctly too.
    • What are examples of these?
    • a ? (b) : c => d
      • Even a ? (b) : (c => d)
        • What!?
        • Yeah, because the (c => d) looks like it's going to be a type annotation, but it's not and we have to fail.
      • a ? b : c => d works
      • a ? ((b)) : c => d works
      • 😄
• The "permissive" option is the one that seems to keep things working in TS.
• Let's come back to these, but revert in the meantime.

Parsing QualifiedName in typeof

#48640

• Issue with unsafety in our parseQualifiedName where existing callers just cast around.

• Means that we have to undo the "feature" where you can allow typeof this.#private.

• Do we... want typeof to work on #privates?

  • Doesn't work on declaration emit.
  • Shouldn't ever work outside the class - a private name is always unique and scoped to the current class. Would become ambiguous in another context.

• When we did typeof, there were situations where you can access something in the value space, but had no name for the type, and there was no workaround anymore.

  • For #private fields, you had a means to do this, you just didn't.
    • Well, inference from initializers, but how common is this?

• Feels like it should be legal, but what would declaration emit be?

• Declaration emit is already a problem with private properties.

  • VERY sketchy - disallowed with typeof this.somePrivate, but not Foo["somethingPrivate] - and when we emit that in a .d.ts file, it will instantiate to any.

    class Foo {
        private somethingPrivate = 1234;
    
        getSomethingPrivate(): Foo["somethingPrivate"] {
            return this.somethingPrivate;
        }
    }
    
    // turns into
    
    class Foo {
        private somethingPrivate;
    
        // oops! this returns 'any'
        getSomethingPrivate(): Foo["somethingPrivate"];
    }

• Revert is uncontroversial, whether we add it back is unclear. We generally feel skeptical of whether we need it.