Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

TypeScript Version: 3.7.0-dev.20191016

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


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 ( {
    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 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:


Issue Analytics

  • State:open
  • Created 4 years ago
  • Reactions:31
  • Comments:10 (2 by maintainers)

github_iconTop GitHub Comments

RyanCavanaughcommented, Oct 30, 2019

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.

jcalzcommented, Oct 20, 2019

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

Read more comments on GitHub >

github_iconTop Results From Across the Web

Documentation - TypeScript 3.7
The other type of assertion signature doesn't check for a condition, but instead tells TypeScript that a specific variable or property has a...
Read more >
Overview - TypeScript
Building on that work, the new Generator type is an Iterator that always has both the return and throw methods present, and is...
Read more >
Assertion functions in TypeScript - LogRocket Blog
Let's explore assertion functions in TypeScript and see how they can be used to express invariants on our variables.
Read more >
Typescript: No index signature with a parameter of type 'string ...
I thought that the issue was that I needed my object key to be a string. But converting them to strings didn't work....
Read more >
Groovy Language Documentation
String thing = 'treasure' assert 'The x-coordinate of the treasure is represented by ... Unlike Java, Groovy doesn't have an explicit character literal....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found