GeezerVison

Do we have an issue open for the following?

function f() {}
f.p = { x: "" };
const { p } = f;
if (1 + 1 < 2) {
    f.p = { x: 0 };
}
f.p.x = 0;
p.x.toUpperCase(); // No compile error, crash at runtime

A hole like that might be acceptable for JS expando objects, but I don't know about having this in .ts files.

Completions will have to be updated to allow f.x as a new identifier location when f is a function. That could be a separate issue.

I opened #26372 to track the type hole you found.

This does not work when the property is a well-known symbol.

function count(start = 0) {
  while (true) {
    yield start;
    start += 1;
  }
}
count[Symbol.iterator] = () => count();

Kaleb Hornsby (@kaleb) that’s not part of the current design; it only applies to property accesses, not element accesses. And it doesn’t handle computed property names at all, even well-known symbols. Can you open a separate issue to track that?

Should TSC verify that every branch leads to an assignment in this case?

type WarnUser = {
  (warning: string): void
  wasCalled: boolean
}

const warnUser: WarnUser = (warning: string) => {
  if (warnUser.wasCalled) {
    return
  }
  warnUser.wasCalled = true
  alert(warning)
}
if (Math.random() < .5) {
  warnUser.wasCalled = false
}
// No error

Boris Cherny (@bcherny) Your example actually doesn't use control flow much, which means that we won't be able to issue a use-before-def error. Let's look at each use of wasCalled:

1. if (warnUser.wasCalled) is inside a closure. It's going to use the declared type, which comes from type WarnUser. Notably, WarnUser.wasCalled doesn't contain undefined and isn't optional.
2. warnUser.wasCalled is also inside a closure. It doesn't count as a declaration since it's not in the same scope as warnUser. It will also use the declared type.
3. Initialisation inside an if. This counts as a declaration so of course won't warn.
   3a. Before the if. There aren't any assignments or ifs here but the declared type isn't optional and doesn't contain undefined, so no error.
   3b. After the if. There is an if with an assignment inside, but they don't change the declared type.

You can do two [interesting] things to change this:

1. Remove the type annotation. The type of warnUser remains the same, but is now anonymous. The declared type is now based on checking warnUser's initialiser, which causes control flow to check warnUser.wasCalled = false, which it treats as an assignment. Now, as desired, (3a) and (3b) give a use-before-def error and you can get (3b) to be correct by adding an else-branch+assignment to the if.
2. Make WarnUser.wasCalled either optional or contain undefined in the type. You'd think this would make it behave the same as with the type annotation, but it has the same control flow behaviour as the original example — you get the declared type almost all the time. The type contains undefined, though, so the checker forces you to narrow that out before using the boolean. It just doesn't give a use-before-def error.

Nathan Shively-Sanders (@sandersn) Thanks for the super detailed explanation of how the typechecker thinks about this example!