Repository navigation
Potential regression in 4.2 - Calling .map on T[] | Y[] is now callable but leads to an implicit any error #42646
Description
Activity
- changed the title
[-]Potential regression in 4.2 - Calling `.map` on `T[] | Y[]` is now callback but leads to an implicit any error[/-][+]Potential regression in 4.2 - Calling `.map` on `T[] | Y[]` is now callable but leads to an implicit any error[/+]on Feb 4, 2021 It's not a regression (definitionally, going from can't call at all to implicitly any is a less restrictive error - now you can explicitly annotate it and actually resolve the call), and we already have #42620 open to improve the experience further~
But why does it allow specifically
map(andsome)?everyandfilterare still errors.related issue: #35045
everyandfilterhave multiple overloads (with differing numbers of type parameters) which makes the union call difficult to resolve, whilemaponly has one overload, so combining the signatures is much more straightforward.Reacted by Georgii DolzhykovIs there any chance for
everyto work for unions of read-only array types in the foreseeable future?Not in the immediate future, no. The
readonly-ness isn't what matters for our ability to check it - the overload count/genericness of the signature is. We've been slowly expanding how much of that we can check, but I can't make any claims as to how far we'll go or by when.I see, thanks. For some reason, I thought these methods are disallowed because of type safety. E.g., what can be
pushed to an array if it's type isstring[] | number[]? So it looked like readonly-ness might help. But now I see I misunderstood the problem.Anyway, wouldn't it be a helpful trick to implicitly transform
readonly string[] | readonly number[]toreadonly (string | number)[]for the purposes of signature merging?[...] and we already have #42620 open to improve the experience further~
Wesley Wigham (@weswigham) It's not clear to me how your PR relates to this issue, do you have a playground link I can poke around with?
Tom Sherman (@tom-sherman) Previously, such calls were disallowed because merging signatures for generic overloaded functions is a tricky procedure, and it wasn't implemented. Now, in some cases, it became possible. After merging that PR, it'll be possible in more cases. Hopefully, we'll read more on that in the release blog post.
Now that it works for
map, I wonder if this issue should be renamed with a mention offilterandeveryin the title, That'd make it more discoverable.An isolated real-world case to demo how this issue is a pain:
playgroundimport * as Babel from "@babel/types"; import { TSESTree } from "@typescript-eslint/typescript-estree"; type Node = Babel.Node | TSESTree.Node; declare const node: Node; if ( (node.type === "GenericTypeAnnotation" || node.type === "TSTypeReference") && (!node.typeParameters || node.typeParameters.params.length <= 2 && node.typeParameters.params.every(n => true)) ) { }
everycauses the following error:This expression is not callable. Each member of the union type '{ <S extends TSType>(predicate: (value: TSType, index: number, array: TSType[]) => value is S, thisArg?: any): this is S[]; (predicate: (value: TSType, index: number, array: TSType[]) => unknown, thisArg?: any): boolean; <S extends TSType>(predicate: (value: TSType, index: number, array: TSType[]) => value is S, thi...' has signatures, but none of those signatures are compatible with each other.(2349)Closing as fixed in #53489; reading the PR, it has this case as a test.
Bug Report
🔎 Search Terms
expression not callable union arrays
🕗 Version & Regression Information
This changed between versions 4.1.3 and 4.2 beta
⏯ Playground Link
https://www.typescriptlang.org/play?ts=4.1.3#code/CYUwxgNghgTiAEYD2A7AzgF3gDwFzxQFcBbAIxBgG0BdeAH3kxgEsUBzGgKE+wDpioABwAUAM3gBeAHzxRASiA
https://www.typescriptlang.org/play?ts=4.2.0-beta#code/CYUwxgNghgTiAEYD2A7AzgF3gDwFzxQFcBbAIxBgG0BdeAH3kxgEsUBzGgKE+wDpioABwAUAM3gBeAHzxRASiA
💻 Code
🙁 Actual behavior
.mapis now callable butfas an implicit type ofany, leading to an implicit any error.🙂 Expected behavior
The current behaviour in 4.1.3 is to mark the
map()call as not callable as well asfshould have an implicit any type.I don't know if this is a regression but I'm raising it because this change in behaviour is not documented in the release notes.