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

[mweststrate]

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

[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).

[mweststrate]

That last type annotation is exactly what I want to avoid. 1. Literal is the simplest example, for complex ones it would be really hard for consumers of the API to know what to put there 2. That last type annotation will make it impossible for this system to work OOTB in ts-checked Javascript files. Op zo 20 okt. 2019 01:29 schreef Joe Calzaretta <notifications@github.com>:

…

This is, unfortunately, working as intended as per #33622 <#33622>, see #33580 <#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 <http://www.typescriptlang.org/play/?ts=3.7-Beta#code/JYOwLgpgTgZghgYwgAgDLDAHgCrIgD0hABMBnZAawgE8B7GZOEagPmQG8AoZH5YUgBQA3OABsArhABcjZgEoZIiSn7JsAbm684pUtDDCxkmU2oLGu-eSWS+5DZwC+nTjHEgEYYLRDJRGaDEcPEIIEnIqOgZTFgF-MBlsc3QsbDYuXmQoCDBxKF8QcVFRC1lqTWdOBB9SMDsACWAZFMwAIgALYFa2AF4-AKgxAQ6uuRdqkFrkfBl3ChBaAHdfPtbIWtaXYAYBfkaAOn4BfDk5Di0eCdJaUQh90VoAc2OzgHpX6btkaqhsz1FqHwQDBoNliMgwLRkAByTrQpxbUgHHR6KAGE6aKo1G53B7PDHId6fUjtWhFcEAIxUwNBEHBOhhcOQtCE0GQ7WgECAA> 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). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#34596?email_source=notifications&email_token=AAN4NBDWWDKH4YGX36X4N63QPOQ6HA5CNFSM4JCQ6252YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBX7NSY#issuecomment-544208587>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBDZJW7LRCUNMJFTEDTQPOQ6HANCNFSM4JCQ625Q> .

[mweststrate]

To elaborate a bit more, how this functionality in general is used, is like:

import { types } from "mylib"

const User = types.Object({
  name: types.string,
  tags: types.array(types.union(types.literal("happy"), types.literal("sad")))
})

// Later
if (User.is(someData)) {
  // someData is correctly inferred to be of type { name: string, tags: ("happy" | "sad")[] }
}
User.assert(someData) // TS Error

This all works splendidly well for typeguards, however, forcing the user to type User explicitly to be able to make asserts as well, partially defeats the purpose of library, as these types get really large in practice (the demo above is still really small).

What is more, to add to the inconsistency (see snippet below), if assertion is extracted as utility function that receives the type as generic argument, it works fine. So it seems that in principle the TypeChecker in principle doesn't have any trouble checking this, but that there is just a hard limit (magic number) put in place somewhere?

type Guard<T> = { is(value: any): value is T }

function assert<T>(t: Guard<T>, value: any): asserts value is T {
    // something
}

assert(isHi, x)

console.log(x); // x is correctly as 'hi' over here

playground

Edit: I am not sure how this relates to CFA; as to infer the type of isHi only the function signatures matter, not the internal flow for how or when that object was constructed?

[jack-williams]

What is more, to add to the inconsistency (see snippet below), if assertion is extracted as utility function that receives the type as generic argument, it works fine.

This is consistent in that assert has an explicit type signature. As @jcalz's says, polymorphism is orthogonal to the cause of the issue - though it does exacerbate to pain because instantiated generic types are usually harder to write explicit types for.

[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.