Repository navigation
Array.isArray refinement loses the array's type #33700
Description
I realize there are a number of related issues. However, some where about ReadonlyArray, some didn't see directly related at all even though it was pointed there.
Also, this is a much smaller example, just a single line of code really:
I know people will point to this ir that implementation or design decision detail — honestly guys, you got it REVERSED. The tool should serve the purpose, not the other way around!
That the array loses all it's type information in such a simple example is A BUG.
And it is possible to do much better: See here! I'm only pointing this out because at times the responses sound like "We tried everything but it is just not possible" when the competition shows that it is actually quite possible.
Related(?): #17002
Activity
MartinJohns commentedon Oct 1, 2019
There simply is no type-information available in the
Array.isArrayfunction for the compiler to keep the type, because it currently acceptsanyas an argument. Changing that would be a heavy breaking change that is not going to happen.You can easily workaround this by providing your own version with more specific types, so there's type information available for the compiler, for example:
jcalz commentedon Oct 1, 2019
Exact duplicate of #32497, which was locked due to violations of the code of conduct. Let's please remember that disagreements should be handled constructively and respectfully.
RyanCavanaugh commentedon Oct 9, 2019
What is the difference between this and #17002?
RyanCavanaugh commentedon Oct 9, 2019
Just to reiterate, the last thing we need is brow-beating about how THIS IS A BUG and YOU ARE SCREWING UP. We're trying to make a good product and we want the right things to happen; just 💩ing on our efforts doesn't make us more likely to take your issue seriously.
jablko commentedon Mar 11, 2022
Ryan Cavanaugh (@RyanCavanaugh) They're very similar. #17002 only mentions
readonly T[](preserving mutability and element type), whereas this one calls out the issue of still-wider typesIterable<T>. Maybe there's a non-generic solution to #17002, à la #42316, because e.g. the intersectionreadonly T[] & readonly unknown[]has typed properties length, concat, join, slice, and 14 more, whereasIterable<T> & readonly unknown[]only has typed[Symbol.iterator]--- length, concat, join, slice, and 14 only exist on thereadonly unknown[]component. A generic parameter is needed to instead make itIterable<T> & readonly T[].Well, just
readonly T[]because that's a subtype ofIterable<T>? https://github.com/microsoft/TypeScript/blob/93c3a30edc7cc4be94bbeb3074a6a678ffd45d3b/src/compiler/checker.ts#L25061