Number type value arguments falsly claim to not over overlap

[Caleb-T-Owens]

Bug Report

🔎 Search Terms

Type Value Comparison Type Domain Overlap TS2367

🕗 Version & Regression Information

• This is an incorrect compiler error
• This behaviour was observed in every version I tried

⏯ Playground Link

Link to the example code

💻 Code

type Tuple<T, Length extends number> = [T, ...T[]] & { length: Length }
type Table<T, Width extends number, Height extends number> = Tuple<Tuple<T, Width>, Height>

class Matrix<Width extends number, Height extends number> {
    constructor(public data: Table<number, Width, Height>) {}

    get isSquare() {
        return this.data.length === this.data[0].length
    }
}

🙁 Actual behaviour

Causes error TS2367: This condition will always return 'false' since the types 'number & Height' and 'number & Width' have no overlap.
There seems to be several issues here:

• Why is number & Height not absorbed into just Height? - Might not be a bug
• Why is it number & Height in the first place? - Might not be a bug
• Why is there an error occurring here? Both Width and Height extend number and thus there should be ample overlap between the two types. - Defiantly an issue.

My best guess at what is occurring is the type checker doesn't have the capability to look at the "parent" of Width and Height and notice that they both have the same "parent"

Casting the types to Width and Height and doing the comparison still has the domain error.

🙂 Expected behaviour

No errors occur

[jcalz]

Related to #47026; comparisons between two generic types are not usually allowed.

The wording of the error message "This condition will always return false because the types Foo and Bar don't overlap" isn't great, in my opinion. I'd prefer something like "Types Foo and Bar are not directly related to each other and comparing them is probably a mistake; if this is intentional, please assert one or both of the expressions to a common type like Foo | Bar." I guess that message is probably going to stay, though... #26592 is open, but #36534 is closed as "won't fix"

[Caleb-T-Owens]

Its certainly disappointing that any checking doesn't occur, but I guess the complexity of the type checker needs to be considered, but it certainly should have a better compiler message needs to be used because it is a valid statement.

[RyanCavanaugh]

I think as part of #26592 we need to remove the "will always return false" verbiage

[typescript-bot]

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