-
Notifications
You must be signed in to change notification settings - Fork 12.8k
asserts this is T
does not narrow type of this
#60140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking βSign up for GitHubβ, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
existing bug: microsoft/TypeScript#60140
It's still related - the generic types used there are red herring, the issue described there is not specific to them. See my comment in that issue, you have the same situation here - when the compiler sees a union it tries to create a composite signature from all of the constituents of that type. That process deliberately skips assertions. |
@Andarist I see. Thanks for confirming.
Is there a technical reason that prevents the compiler from making it work? or is it just not implemented yet? |
Not quite sure what to do with this. It's obviously safe to maintain the predicateness when the asserted type in every signature is identical. But only identical identical (i.e. mutual subtyping is not sufficient) is safe to do that, and we run into problems when we expose "identity" as a concept because you run into problems, e.g. if instead you had written type X1 = { y: string; x: string };
type X2 = { x: string; y: string };
class A {
onlyDefinedInA() {
console.log("A");
}
assertA(): asserts this is X1 { }
}
class B {
assertA(): asserts this is X2 { }
}
type C = A | B; then this "wouldn't work" and we get bug reports that "X1 and X2 are identical" for some definition of "identical" and it just looks like a different kind of bug. Or, worse, people start writing new cursed variants of So anyway I don't disagree it's suboptimal, but I am really not convinced that any known cure is better than the disease in this situation. |
@RyanCavanaugh thanks for the detailed follow up! In that case, at least until there is a better/future-proof way to support this, I wonder if it can be an explicit error in the meantime, to save future users time debugging/root causing this like I did. Unfortunately the current type information surfaced in the IDE indicates it should succeed (playground link above): |
This is related to #28159 you can't change the value of a variable partway through a function. For the same reason that
you also get that
I agree it's unfortunate since this would be a useful functionality for builders so you don't have to construct a builder in one giant chain |
π Search Terms
asserts this is T
narrow
assertions
π Version & Regression Information
v5.7.0-dev.20241004
v5.6.2
β― Playground Link
https://www.typescriptlang.org/play/?#code/MYGwhgzhAECC0G8BQ1oHsB2ICeARApgGYCWG+AJgJIawAUAlIiqtMJhGiPgHQhoDmtAESwh9ANzMAvkmaQI+AE4AXOvQBc0eUuUxlAC2IwjcRNBkzZoedABCTVNpVrNT3dAMmT8BOaSXlbAAHfGgAYWgAXlMAHztJJEIAVwxgZWJMLSgdOmBNMI0shRUYYGhvJktk1PTM5XwIZQBGWjzwxmRUYG43NUku7kwcAhIyKhoGcWgAemnoAFFFRTRFTQAFZZCVbGgAciG8IlIKalhd6HI0BugMNGVofAAPI3u64NDdsN3uaA20LcCewOI2O4zOFyuMFu9yeL3QGA87z2tm+-lk1TSGQR9UaACZWvkOnJss5WhJmN1gUcxqdJjM5gB1FYAawgAEI0dAgA
π» Code
Workbench Repro
π Actual behavior
Type of
c
is not narrowed after the method call, producing an error.π Expected behavior
I expect the member function to to perform type narrowing.
Additional information about the issue
No response
The text was updated successfully, but these errors were encountered: