typeof operator fails on use-before-defined block scoped variable.

[sccolbert]

TypeScript Version:

1.8.0

Code

interface IThing<T> {
    owner: T;
}

var foo = {
    one: null as IThing<typeof foo>, // okay
}

let bar = {
    two: null as IThing<typeof bar>, // fail
}

Expected behavior:

The let definition should compile, since the typeof operator has no runtime effect.

Actual behavior:

The let definition fails with a "used before declaration" error.

[markwongsk]

Would this be a suitable bug for a first-timer?

[RyanCavanaugh]

I imagine it will be pretty easy. There are lots of other places where we special-case use of an identifier inside a typeof so there are some examples to work from.

[markwongsk]

I don't think this is a special-casing of typeof. For example, the example above works for a var foo declaration, but not a let bar declaration. Other manifestations of this problem include:

var baz = { 
    one: baz, // valid
};

let ack = { 
    one: ack, // fails
};

var a = [ a ]; // valid
let b = [ b ]; // fails

I think the reason for the differences is the following lines in checker.ts (revision 6e4dd75, line 890):

                if (meaning & SymbolFlags.BlockScopedVariable) {
                    const exportOrLocalSymbol = getExportSymbolOfValueSymbolIfExported(result);
                    if (exportOrLocalSymbol.flags & SymbolFlags.BlockScopedVariable) {
                        checkResolvedBlockScopedVariable(exportOrLocalSymbol, errorLocation);
                    }
                }

Since the let causes the variable to be block-scoped, this eventually triggers the check isImmediatelyUsedInInitializerOfBlockScopedVariable. At this point, I'm wondering if this was an explicit design decision. It seems like under the ECMAScript specification, baz and a are valid whereas ack and b are not, which leads me to want to conclude that the current implementation is correct.

[RyanCavanaugh]

The runtime behavior is mostly irrelevant to how the type system can behave. There's not anything preventing us from figuring what's going on in a block like this

let a: typeof b;
let b: string;

[markwongsk]

My understanding of https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#3.8.10 is that the b in typeof b needs to be typechecked as an identifier reference expression. Am I missing something here?

[markwongsk]

@RyanCavanaugh sorry if I'm misunderstanding the scope of this fix. But my interpretation of the spec leads me to conclude that this is the correct behavior (as I've explained above). And I wasn't sure a first-timer bug would involve changing the specification.

[DanielRosenwasser]

@markwongsk just because the entity is being type-checked doesn't mean that TypeScript needs to consider it "used" before its definition in any manner that matters. Like Ryan mentioned, block scoping only matters when used in a value position, but when used as part of a type, there really isn't a reason to impose the restriction.

At best, it seems like the spec leaves it unspecified from what I can see.