Assertion methods (`asserts this is`) are not CFA'd without error

TypeScript Version: 4.0.5, 4.1.0-beta, 4.2.0-dev.20201112

Search Terms:

• Multiple assertion methods
• "asserts this is"
• assertion "cfa"

Code

class X<T, Locked extends boolean> {
    public x: null | T | (Locked extends true ? 1 : 2) = null

    public assert<U>(): asserts this is X<U, Locked> { }
    public lock(): asserts this is X<T, true> {}
}

const x: X<string | number, false> = new X<string | number, false>()

x.assert<string>()
// x is X<string, false> here

x.lock()

Expected behavior:

Either:

• After x.lock(), x is narrowed to X<string, true>
• Or, the x.lock() line throws at compile-time due to not being CFA'd

Actual behavior:

After x.lock(), x is narrowed to X<string, false> & X<string | number, true>.

Playground Link: https://www.typescriptlang.org/play?ts=4.2.0-dev.20201112#code/MYGwhgzhAEAaA8AVANNAMge2AawKYBNpcAPAF1wDt8YAjDDEXMCgPmgG8BYAKGj+gAOAVxogAlsGjEAXNApCQIaAB9oiFdAAUmHASJlK1aKQBOQ3NAD80AIzRZAJgCU0ALxyFIHj36CR4yUgIXBNSeABVFk0nWSCQ0hhSAAsxGFS4CNQdPHw2dmgAXx9+YVEJaBAsbGjYqHjElLSYBBRjM1w8ou4unmAMCghSKVkEQZMxCgBzDXkAWxoQ1AAzMBBgtncKXAB3DLGJ6dU5hZNl1fXo725iADo40Ph9qainHgB6N6lodNHTA7O1h1oEkQrgrvhcKAwCYLEshBRgKQxP0KlUkFEAG4jJCoOgMJisGLQe4JaAY77NHFtcwsK63So4S7cIA

Analysis:

x being typed as X<string, false> & X<string | number, true> shows that the x.lock() narrows from the original type (X<string | number, false>) instead of the narrowed type at that position (X<string, false>).

If instead a "top-level" assertion function is used the type is properly narrowed:

class X<T, Locked extends boolean> {
    public x: null | T | (Locked extends true ? 1 : 2) = null

    public assert<U>(): asserts this is X<U, Locked> { }
    public lock(): asserts this is X<T, true> {}
}

const x: X<string | number, false> = new X<string | number, false>()

x.assert<string>()
// x is X<string, false> here

declare function lock<T>(v: X<T, boolean>): asserts v is X<T, true>
lock(x)

Playground

This leads me to believe this is an issue with the x.lock() call not being CFA'd, in which case the correct behavior would be to throw ts(2775) on the x.lock() line.

Comienza ejecutando la reproducción proporcionada en TypeScript Playground y compara el narrowing del flujo de control después de x.assert<string>() y x.lock(). Investiga cómo el compilador maneja los métodos asserts this is y el tipo de intersección reportado. Se considera completado cuando la segunda assertion hace narrowing a X<string, true> o informa del error esperado en tiempo de compilación, con cobertura de regresión para el ejemplo.