types of A[] || B[] and A[] ?? B[] are incorrect if A is a subtype of B

[Alexsey]

Bug Report

🔎 Search Terms

Arrays, null coalesce, OR operator, subtype reduction

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about

⏯ Playground Link

Playground link with relevant code

💻 Code

declare const a: { x: string }[] | undefined
declare const subA: { x: string, y: number }[]
declare const notSubA: { y: number }[]

const good = a || notSubA // { x: string }[] | { y: number }[]
const bad = a || subA // { x: string }[]

🙁 Actual behavior

bad is { x: string }[] (type of a but without undefined)

🙂 Expected behavior

bad should be { x: string }[] | { x: string, y: number }[] (a union of a and subA without undefined).

Type of || should not depend on the relationship between types of operands

Notes

null coalesce ?? suffers from the same problem

[fatcerberus]

Subtype reduction is intended behavior. Duplicate of #46449 and others - search issues for “subtype reduction”. This comes up quite often and should probably be mentioned in the FAQ at this point.

[Alexsey]

@fatcerberus thank you for the fast reply! I can see now it's an unfortunate design bug. I've added "subtype reduction” to the Search Terms list

[fatcerberus]

It's admittedly annoying, but not really a bug. Technically the types { x: string } | { x: string, y: number } and { x: string } are equivalent since in both cases you might have ended up with, e.g. a { x: string, y: boolean } (see #12936); you can't actually safely assume anything about y (or any property other than x for that matter) in either case.

[Alexsey]

@fatcerberus I'm afraid I have to disagree with your argument about the safety of the union of subtypes vs. the union of non-subtypes because your logic can be applied the same way to the non-subtype case:

type A = { a: string }
type B = { b: number }

function foo (x: A | B): string {
    if ('a' in x) {
        return x.a.toUpperCase()
    }
    return `${x.b}`
}

const runtimeCrashArg = {a: true, b: 22}

foo(runtimeCrashArg) // no error

Any union type allows such kind of type violation regardless of if the union members are bivariant or not

[fatcerberus]

Yes, in checks are known to be unsound (and narrowing based on in wasn't implemented for a long time for that reason). What I was getting at was that, if the type rules were enforced consistently and this kind of unsound narrowing wasn't possible, subtype reduction would produce fully equivalent types and is therefore not a bug in and of itself.

[fatcerberus]

Ah, this is what I was referring to: #53425 (comment)
For the record, I do agree this is a real nuisance in many cases - it's just not likely to ever be considered a bug since it aligns with the rules of the type system as designed.

[github-actions]

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