TS 3.7: unlike `x is T`, `asserts x is T` cannot close over generics defined in outer scopes

TypeScript Version: 3.7.0-dev.20191016

Search Terms: asserts, asserts return, asserts higher order, asserts type, 2775

Code

function literal<T extends keyof any>(lit: T): {
    is(value: any): value is T
    assert(value: any): asserts value is T
} {
    return null as any; // implementation doesn't matter
}

const isHi = literal("hi")
const x: unknown = "test"

if (isHi.is(x)) {
    console.log(x) // x is correctly inferred to be 'hi' :)
}

isHi.assert(x); // error: Assertions require every name in the call target to be declared with an explicit type annotation.(2775)
console.log(x); // x should be inferred to be 'hi' here :(

Expected behavior:

No compile error, x is inferred to be "hi" on the last line.

Actual behavior:

Compile error on isHi.assert. Assertions require every name in the call target to be declared with an explicit type annotation.(2775)

Construction higher order type guards is possible without problem (as shown in the snippet). This mechanism used heavily in libraries like io-ts and mobx-state-tree.

However, when trying to extend the latter library with assertion functionality for more convenient control flow, we run into this issue.

We can build type.is properly, but not type.assert, although they seem to be needing the exact same type / depth of type analysis; if type guards can close over T, so should type assertions?

Playground Link: link

Related Issues:

#34523

[RyanCavanaugh]

The issue here is that we need the information about the assertness of a function early enough in the compilation process to correctly construct the control flow graph. Later in the process, we can detect if this didn’t happen, but can’t really fix it without performing an unbounded number of passes. We warned that this would be confusing but everyone said to add the feature anyway 🙃

I think it would be tractable to produce a quick fix in many places, since we (should?) know the originating declaration, know how to write the type down (if possible) in the context of that declaration.

[jcalz]

This is, unfortunately, working as intended as per #33622, see #33580. The issue is not about closing over generics, but about the fact that your isHi variable is not typed via explicit type annotation. The error message says as much, I guess, but it is bewildering, and I expect you won’t be the last person bewildered by it. The fix is something like:

interface Lit<T extends keyof any> {
    is(value: any): value is T;
    assert(value: any): asserts value is T;
}

function literal<T extends keyof any>(lit: T): Lit<T> {
    return null as any;
}

const isHi: Lit<"hi"> = literal("hi")

Playground Link

in which you are forced to write out a type like Lit<"hi">.

---

This is clearly going to be a pain point with user-defined assertion functions once 3.7 is out of beta. Is the current error message really the best we can do? Anyone have any great ideas? I was hoping the error would come with a “quick fix” that suggests some suitable annotation somewhere, but I guess that would be too hard to get right (if the compiler could always figure out what the annotation should be I guess the annotation wouldn’t be necessary in the first place).