Uncaught uninitialized class member with Symbol key

[soul-codes]

TypeScript Version: 4.1.0-dev.20200917

Search Terms:
symbol class member uninitialized

Code

const Foo = Symbol()

class WithFoo {
  [Foo]: any[]; // this shouldn't be allowed without an initialization in a constructor
  Foo: any[]; // compare with this, which errors as expected
}

console.log(new WithFoo()[Foo].length) // uncaught uninitialized symbol member, oops

Expected behavior:
An error like Property 'Foo' has no initializer and is not definitely assigned in the constructor should also be emitted for the symbolic property Foo.

Actual behavior:
No such error is thrown.

Playground Link:
here

[andrewbranch]

Actually, it looks like this is true of any computed property declaration 😦

https://www.typescriptlang.org/play?ts=4.0.2#code/MYGwhgzhAEDqCWAXAFgMQPbugbwFDWgG0AiAI3GWIF0AuaMAOwE9CqBufaDdOxl93AF9cuYOgYR0IAKYA6EOgDmACgbSA7nCRpMygJSzyYZPOkNFKPdAD016JgAOEIA

[a-tarasyuk]

isPropertyInitializedInConstructor doesn't support ElementAccessExpression, only PropertyAccessExpression.

function isPropertyInitializedInConstructor(propName: Identifier | PrivateIdentifier, propType: Type, constructor: ConstructorDeclaration) {
    const reference = factory.createPropertyAccessExpression(factory.createThis(), propName);
    setParent(reference.expression, reference);
    setParent(reference, constructor);
    reference.flowNode = constructor.returnFlowNode;
    const flowType = getFlowTypeOfReference(reference, propType, getOptionalType(propType));
    return !(getFalsyFlags(flowType) & TypeFlags.Undefined);
}

I think isPropertyInitializedInConstructor can be extended to use both ElementAccessExpression and PropertyAccessExpression, however, I'm not sure that getFlowTypeOfReference can resolve the right type for ElementAccessExpressions with Identifiers.

const Foo = Symbol()
class WithFoo {
  [Foo]: any[];
  ["prop"]: any[];

  constructor() {
    this[Foo] = []; ??
    this["prop"] = []; // Works
  }
}

@andrewbranch What do you think?

[andrewbranch]

@a-tarasyuk you’re right, that would require #36230. Maybe the current behavior is intentional, then, as we’re looking at a choice between always¹ issuing the uninitialized error or never issuing it. 😕

¹ “always,” unless the initialization is on the class field itself, or the error is suppressed with !. These are pretty good as workarounds go, but I’m not sure they’re good enough to merit this change.

[andrewbranch]

I don’t know though, it seems like issuing the error when there is no constructor would be better than nothing...