Repository navigation
never as keyof tuples/arrays behaves the same as number #55841
Description
🔎 Search Terms
tuple keyof never, tuple[never], array keyof never
🕗 Version & Regression Information
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about this issue
Versions I tried:
- 5.2.2
- nightly (playground)
⏯ Playground Link
💻 Code
type A = {}[never] // ✅ never
type B = { a: string }[never] // ✅ never
type C = [][never] // ✅ never
type D = [string][never] // ❌ string
type E = string[][never] // ❌ string
type F = (string | number)[][never] // ❌ string | number🙁 Actual behavior
After using a never key on tuples/arrays you get back the entirety of the tuple/array elements type.
🙂 Expected behavior
After using a never key on tuples/arrays you get back never, as when dealing with objects.
Additional information about the issue
Not sure if this has historical reasons to behave like it does, but couldn't find any specific info about it.
Activity
MartinJohns commentedon Sep 23, 2023
Is there an actual issue you had with this behaviour? It sounds awfully lot like this issue and comment: #53345 (comment)
kristiannotari commentedon Sep 24, 2023
Couldn't find that one! Thanks for pointing that out.
There are no unsolvable problems to be honest, because with your custom types you can workaround the "unexpected" behaviour quite simply.
My actual use case is a "find if there are duplicates in tuple" type. My approach was to deconstruct the tuple with its indexes and check if the current element is assignable to one of the types in the union of the other tuple keys. What's interesting is that by simply stating this, you can see why returning the whole tuple/array element type when indexing with
neverdoesn't seems to be "right", when manipulating tuples/arrays.Implementation example:
I'm basically mapping each element of the tuple to a "Duplicate" or "NotDuplicate" type so to check if any of the elements is duplicated.
The
HasDuplicatestype, since indexing withneverequals to the whole tuple elements type, requires a special case handling for it, instead of being able to apply what I'd call "a reasonable enough approach". It seems fine to me to think about the problem's solution as: "check if any tuple element is equal to any other tuple element". Encoding this logic directly, which seemed correct at first, introduces a subtle bug with 1 elements tuples, forcing a special case handling.Not to say this is the best approach to this problem, but surely the special case handling seems not intuitive.
Behaviour example (without the special case handling):
To make the impl work as intended you need to add the special case handling for 1 elements tuple:
edit: pasted the wrong impl example
edit2: playground link as reference for examples
RyanCavanaugh commentedon Sep 26, 2023
Happy to take a PR on this one now that we have an example of where it might matter
jfet97 commentedon Sep 27, 2023
Ryan Cavanaugh (@RyanCavanaugh) I closed my PR because in the past a similar issue was closed as "Working as Intended". But now that this issue has been marked as a "Possible Improvement" I re-opened it: #55842. Could you check it out?