index never on tuple returns union

[unional]

Bug Report

[1, 2][never] // 2 | 1

Is this a bug?

🔎 Search Terms

index, never, tuple

🕗 Version & Regression Information

TypeScript: 3.2 - 5.0.2

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

⏯ Playground Link

Playground link with relevant code

💻 Code

[1, 2][never] // 2 | 1

🙁 Actual behavior

[1, 2][never] // 2 | 1

🙂 Expected behavior

[1, 2][any] // 1 | 2

[1, 2][never] // never ----or Error: A tuple type cannot be indexed with `never`.----

// is the similar reasoning as:
[1, 2][2] // Tuple type '[1, 2]' of length '2' has no element at index '2'.
[1, 2][-1] // A tuple type cannot be indexed with a negative value.

UPDATE:

or Error: A tuple type cannot be indexed with never

is strike out, as the expression [1, 2][never] is value as:

$$keyof [1, 2] \in never$$

[Andarist]

This happens for all index signatures, for example:

type Rec = Record<string, boolean>[never] // boolean

isApplicableIndexType here just ends up calling isTypeAssignableTo(source, target) and... well, never is assignable to everything.

[unional]

Yes, never is assignable to everything:

const x: number = 1 as never

The question is what does Array<T>[never] mean.

type X = ['a', 'b'][any] // 'a' | 'b'
type Y = ['a', 'b'][number] // 'a' | 'b'
type Z = ['a', 'b'][never] // 'a' | 'b'

playground

any and number is a superset of 0 and 1, so yielding 'a' | 'b' make sense as the category is mapped correctly. number is narrowed to 0 and 1 thus the result is the union of values.
(UPDATE: or may be not? Maybe resolving to 'a' | 'b' | undefined make more sense? Or since any and number contains invalid index types such as negative number or non-number, it should be invalid?)

But never supposed to be the bottom type of everything. From handbook:

The never type is a subtype of, and assignable to, every type; however, no type is a subtype of, or assignable to, never (except never itself). Even any isn’t assignable to never.

So to me yielding 'a' | 'b' doesn't sound right.

[unional]

btw, while union order doesn't matter, [1, 2, 3][number] yields 2 | 1 | 3 instead of 1 | 2 | 3 is kind of weird.

Playground yields 3 | 1 | 2 instead...
Both Playground and local in my computer (Windows 7) are using TypeScript 5.0.2.

playground

[fatcerberus]

Union order is a pure implementation detail: It depends on the order the constituent types are first instantiated by the compiler and thus can change depending on the surrounding code, the order in which files are compiled (in a multi-file project) or even with different compiler settings. For all intents and purposes, you should treat it as random.

[RyanCavanaugh]

I don't follow the logic in the OP at all.

• Indexing [1, 2][keyof [1, 2]] is legal
• never is a legal keyof [1, 2]
• Therefore [1, 2][never] is legal too

I think you could argue either way whether the "correct" bound on that type is [1, 2] or never, but plainly both are sound. Absent a more concrete argument for changing it, I don't see what the goal is here.

[unional]

Yes, never is a legal value of keyof [1, 2] = (0 | 1) as never is considered as the "empty union" ().

And yes, the question should focus on what it resolves/bounds to.

The problem and confusion is that the current behavior does not map logically.

Consider type as set:

$$never \in 0 \in (0 | 1) \in any$$

When mapped using "functor" [1, 2][N], the result is:

[1, 2][never] // 1 | 2
[1, 2][0] // 1
[1, 2][0 | 1] // 1 | 2
[1, 2][any] // 1 | 2

That means:

$$never \in 0 \in (0 | 1) \in any$$

is transformed to

$$(1 | 2) \notin 1 \in (1 | 2) \in (1 | 2)$$

meaning never, which is a bottom type of all, is mapped to a larger set then its superset.

That's why [1, 2][never] // 1 | 2 should be incorrect.

It should resolve to never

[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.

[unional]

Reopen?

[RyanCavanaugh]

I'd consider it, but again, a motivating scenario is needed given that the current result is still a correct upper bound.

[unional]

Do you think my reasoning here is correct? #53345 (comment)

That tries to reason that returning 1 | 2 is the incorrect behavior.

[RyanCavanaugh]

I think your logic and my logic are both correct, and both create correct upper bounds.

Generally we've found it's disruptive to just go change stuff without being able to point to a code example and say "We made this work now" as justification for making those changes. Inevitably, changes cause breaks, and people want to know why you broke them, and there should be a better answer than "Someone used ∈ correctly"

[unional]

No problem. I understand that changes could break someone else's code.

I understand that TypeScript need to make trade-offs, balance between usability vs soundness.

It might even be too late to change now, but things like these make the type system harder to reason, thus make it harder to understand and write correct (type-level) code.

I'm going to have this logic in the At<A, N> type in type-plus. i.e.:

type R = At<[1, 2, 3], never> // never

This way, there is at least some way to obtain that behavior.