Array.isArray type guard not working in 5.0

[Hypnosphi]

Bug Report

🔎 Search Terms

Operator '>' cannot be applied to types

🕗 Version & Regression Information

• This changed between versions 4.9.5 and 5.0.2

⏯ Playground Link

Playground link with relevant code

💻 Code

declare const a: readonly number[] | number

const isPositive = Array.isArray(a) ? a.every(x => x > 0) : a > 0

🙁 Actual behavior

Operator '>' cannot be applied to types 'number | readonly number[]' and 'number'.

🙂 Expected behavior

No error, as Array.isArray(a) is true for arrays

[ahejlsberg]

The thing that changed here is that we more strictly check the > operator. In both 4.9 and 5.0, the type of a in the false branch is readonly number[] | number and not just readonly number[]. The reason for that is that Array.isArray checks against a non-readonly any[].

[zardoy]

The reason for that is that Array.isArray is checks against a non-readonly any[].

Also run into it recently, but #17002 captures the issue here. This workaround #17002 (comment) fixes your problem

[fatcerberus]

The reason for that is that Array.isArray is checks against a non-readonly any[].

Hmm, so the upshot is that there's a (built-in!) type predicate that can return true for something which is known to not match the check type (readonly number[] is not a valid any[])... seems like that's something that should be fixed.

[RyanCavanaugh]

There's no defect here. The above example is basically the same as

declare const a: Animal | Plane;
const p = Cat.isCat(c) ? c.meow() : c.fly()

But obviously a could be a Dog, which can neither meow nor fly.

If you made a new (structural) type that had all the members of Array except push, then that'd be legal to inhabit a, but if Array.isArray returned true for it, then you'd be allowed to call push on it, which is wrong, but if Array.isArray returned false for it, then we'd incorrectly say that a is a number in the false case. What people really want is a function that says "does it have all the non-mutating members of Array?", but that isn't what Array.isArray does.

I think the intuition is that readonly number[] means "A fully-real Array, but I pinky-promise not to mutate it" but, FBOFW, that's not what it is.

[fatcerberus]

@RyanCavanaugh I’m not sure I follow the analogy - Cat.isCat() would clearly return false for a Dog, but Array.isArray returns true for all possible inhabitants of readonly number[]. So it’s more like calling Animal.isAnimal(). At any rate this feels like it makes Array.isArray largely useless as a type guard.

It still feels like a defect because effectively what we have here looks like function isAnimal(x: unknown): x is Cat

[RyanCavanaugh]

but Array.isArray returns true for all possible inhabitants of readonly number[]

According to our type system, it doesn't. Any object with all the non-mutating members of Array<T> is a legal readonly T[].

[fatcerberus]

According to our type system, it doesn't.

Indeed, so what we have in practice is an isAnimal masquerading as an isCat, because basically 100% of readonly T[] in real code are going to be real arrays at runtime. My recent comment in another issue about “sleight of hand” in the type system has never felt more relevant 😅

[RyanCavanaugh]

It's funny (like actual ha-ha funny) to me how doing the theoretically-correct thing is either clearly correct on its own merits, or total wonky weirdness, depending on who's looking at it when. I know my own view bounces around all the time on that kind of thing!

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[jcalz]

For what it's worth I think it's unfortunate that this behavior is "working as intended". I have a hard time worrying about theoretical non-Array objects that structurally match readonly any[], when nobody worries about theoretical non-Array objects that structurally match any[]. And it is theoretical, right? Does anyone know of real-world code that makes use of such a monster and which also uses Array.isArray() on it?

[crizzis]

I think the intuition is that readonly number[] means "A fully-real Array, but I pinky-promise not to mutate it" but, FBOFW, that's not what it is.

This misses the point of what the purpose of type guards is. A type guard is supposed to answer the question: 'is this type safely assignable to X', and of course, a T[] is safely assignable to a readonly T[], because it has a narrower interface.

(the other way around would of course be wrong, but that's not what is being discussed here)

(also, isn't I pinky-promise not to mutate it the whole idea behind readonly arrays? If I am a function and my parameter is of type readonly, then I am making a promise to reference the parameter as if it were readonly, there's literally nothing more to it than that).

[jcalz]

If there were a non-Array object o assignable to readonly any[] but not assignable to any[], then Array.isArray(o) would certainly return false. Currently that means "o is not an any[]", which is valid. But the suggestion here would make that mean "o is not a readonly any[]", which is invalid. So the suggestion does seem to hinge on the prevalence of these theoretical non-Array objects that conform to readonly any[] but do not conform to any[]. I am skeptical that such things exist, though.

[Peeja]

FWIW, an example I've just hit: I have a variable which is a JSON value type. I want to know if it's a (non-array) object. I can exclude most things with typeof value === 'object', but that leaves arrays in.

The trick is that I'm working with readonly types. My type looks like JsonObject | readonly JsonValue[]. I'd like to narrow to JsonObject using !Array.isArray, but I can't, because it would only exclude mutable arrays from the type, even though I'd successfully filter out even a frozen array at runtime.