-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Inference from multiple signatures produces unknown
instead of any
#31189
Comments
Well, |
Update: here's a more isolated repro that removes the dependency on interface Bullean { }
interface BulleanConstructor {
new(value?: any): Bullean;
<T>(value?: T): value is T;
}
interface Ari<T> {
filter<S extends T>(callbackfn: (value: T) => value is S): Ari<S>;
filter(callbackfn: (value: T) => unknown): Ari<T>;
}
declare var Bullean: BulleanConstructor;
declare let anys: Ari<any>;
var xs: Ari<any>;
var xs = anys.filter(Bullean) @weswigham Could this be because T ⇏ {} but T ⇒ unknown? I thought our rules for that assignability from type parameters were also incorrect until this change, but maybe not. |
This change can technically fix this specific occurrence of the problem interface Bullean { }
interface BulleanConstructor {
new(value?: any): Bullean;
- <T>(value?: T): value is T;
+ <T extends any>(value?: T): value is T;
} My hunch is that there's a weird interaction between the subtyping pass for overload resolution, the changes of implicit bounds, and...something else? |
If I had to guess, it's because everything is a proper subtype of |
None of those steps are incorrect then. Sigh. In fact they're better because there are fewer hacks. OK, I'm going to:
|
Urrrr.... I'd not consider that a good fix, in the context of #29571 . Reordering the overload would be better, imo. |
Reordering the overloads of |
So far, both master and release-3.4 find their respective signatures on the subtype pass. |
Oh, right, reordering the overloads isn't going to help the subtype thing. Just change the constructor parameter type from |
nop |
I'm not sure if the phrasing here is actually alluding to something else, but if there's a hacky assignability check we removed against unconstrained type parameters, why did we remove it? |
Edit: in response to @DanielRosenwasser, this isn't really a constraint of a type parameter, it's an instantiation of it (
|
Update.
|
#30637 breaks webpack in 3 places in a method chain starting with
anys.filter(Boolean).reduce(...
. Discovered by the user tests.Note that this stops happening when there is only one signature. As soon as there are multiple signatures of either kind, it repros.
Code
(Edit: switched to isolated repro)
h/t @RyanCavanaugh for the type name
Bullean
Expected behavior:
xs : any[]
Actual behavior:
xs : unknown[]
The text was updated successfully, but these errors were encountered: