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 <[email protected]>:

…

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.

[Zemnmez]

I don't really understand much of this but I tried this today and couldn't make it work. is the takeaway that assertions won't work with polymorphism?

[ianstormtaylor]

Ran into this exact thing while trying to see how Superstruct could be made more useful for TypeScript and automatically infer the return types whenever people constructed validations.

[ianstormtaylor]

@RyanCavanaugh I wanted to add a weird behavior that I encountered about this... It seems like there's a difference in this behavior across package boundaries.

For example, given package 'a' which creates an "asserter":

export interface Asserter<T> {
  assert(x: unknown): asserts x is T;
}

export const create = <T>(): Asserter<T> => null as any;
export const number = () => create<number>();
export const Number = number();

If you import it in package 'b' the assertion works only if you use the pre-defined asserter, and don't create a new one from the factory:

import { Number, number } from "a";

{
  const x: unknown = 42;
  Number.assert(x);
  x;
  // This one works fine, and `x` is known to be of type `number`.
}

{
  const x: unknown = 42;
  const N = number();
  N.assert(x);
  // (method) Asserter<number>.assert(x: unknown): asserts x is number
  // Assertions require every name in the call target to be declared with an 
  // explicit type annotation.ts(2775)
  // index.ts(12, 9): 'N' is declared here.
  x;
}

Here's the reproduction as a repo to clone.

Even further, if you actually inline the logic from package 'a' as a file inside package 'b' and import it with './a', both of the examples will error.

---

I kind of assume this is "expected" given the internal limitations of how this feature is written, but externally it feels weird and adds confusion.

For an example of confusion in the wild, there's a library called runtypes which has added an .assert method to its validators, and currently it has this halfway-working behavior. For example:

import { Number, Array } from 'runtypes'

const ArrayOfNumbers = Array(Number)

Number.assert(x) // works!
ArrayOfNumbers.assert(x) // fails!

[mmkal]

We 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 🙃

@RyanCavanaugh I won't pretend I fully understand what a "pass" is, but was it considered to "count" the number of "passes" and throw an error similar to the Type instantiation is excessively deep and possibly infinite if there are more than some reasonable limit? I'm not sure whether that would help, I don't know how many passes the examples in this issue would require, for example.

[mmkal]

It's possible to workaround this in a strange way, by assigning the assertion function to itself, with a redundant type annotation. Example with io-ts:

import * as t from 'io-ts'

export const getAsserter = <A>(type: t.Type<A>) => (val: unknown): asserts val is A => {
  if (!type.is(val)) {
    throw Error('Invalid input')
  }
}

const _assert = getAsserter(t.type({foo: t.string}))
const assert: typeof _assert = _assert

export const printFoo = (x: unknown) => {
  console.log(x.foo) // error: Object is of type 'unknown'
  assert(x)
  console.log(x.foo) // ok: x now has type {foo: string}
}

👆 the above breaks if you remove the pointless-looking type annotation in const assert: typeof _assert = _assert.

Playground link

[alecgibson]

Came here also wanting to work with io-ts, so building on @mmkal 's answer, you can make calling code a tiny bit prettier by naming and inlining the (redundant) asserter type definition:

import * as t from 'io-ts'

export const getAsserter = <A>(type: t.Type<A>) => (val: unknown): asserts val is A => {
  if (!type.is(val)) {
    throw Error('Invalid input')
  }
}

export type Asserter<T> = ReturnType<typeof getAsserter<T>>;

Then in some other module:

const Foo = t.type({foo: t.string})
type IFoo = t.TypeOf<typeof Foo>;
const assert: Asserter<IFoo> = getAsserter(Foo);
assert(foo);
foo.foo // ok
// @ts-expect-error :: invalid property
foo.bar // not ok

EDIT: Realised the above code still isn't ideal, because you can instantiate Asserter<T> with any type parameter and apparently TypeScript doesn't mind that 🤷🏼 (eg this compiles: const assert: Asserter<string> = getAsserter(Foo))