Skip to content

Add undefined to tuple index signature, or reject keys that are not "keyof tuple" #38779

Open
@lonewarrior556

Description

@lonewarrior556

Search Terms

Tuple index signature

Suggestion

I am opening up this issue as Seperate from #13778 since I am ok with the current interpretation of the Array.

declare var strArray: string[] // infinitely long list of type string
var a : strArray[10 as number]  // ok; a is string

but this fails in conjunction with tuples

declare var strTuple: [number, number] // length = 2
var a : strTuple[10 as number]  // absolutely not ok; a is string; 

Better Options:

var a : strTuple[10 as number] should either be string | undefined or it should give a type error similar to:

var a = { 0:  10, 1: 20} as const;
a[10 as number]; // type 'number' can't be used to index type

Tuples are already aware of boundaries and properly return undefined for more specific number types:

const t0: [string][0] = 'hello' // ok
const t1: [string][1] = 'hello' // Type '"hello"' is not assignable to type 'undefined'.

// therefore this is already true!
const t2: [string][0|1] // string | undefined 

why would type number act any differently?

Use Cases

// Easy fix for for loops

for (let i = 0 as 0 | 1; i < 2; i++) { 
  var definitly_string = strTuple[i] // type string
  var j = i + someNumber;
  var not_definitly_string  = strTuple[j] //lets you know you need to be careful
}

You could use keyof typeof strTuple instead of 0 | 1 when you fix this #27995

for (let i = 0 as keyof typeof strTuple; i < strTuple.length; i++) { 
  var definitly_string = strTuple[i] // type string
  var j = i + someNumber;
  var not_definitly_string = strTuple[j] //lets you know you need to be careful
} 

Given that strictNullChecks still allow typed arrays to do this:

var notString1 = strArray[Infinity]; // no error, not undefined
var notString2 = strArray[NaN]; // no error, not undefined

It would be nice to have a mechanism that could allow you to declare arrays with better type safety.

Examples

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Awaiting More FeedbackThis means we'd like to hear from more people who would be helped by this featureSuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions