Literal Tuples/'as const' - allow lib creator to mark type parameters as 'as const' to allow for better TS DSLs #59380

🔍 Search Terms

• tuple as const
• literal tuple as const

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

The simplest thing that comes to mind, is to be able to use 'as const' in type definition, and have arguments of function using this type have 'as const' modifier active without specifying it on the side of function call

const test = <Tuple extends Array<any> as const>(data: Unique<Tuple>) => {}

test([
	{ type: 'Error-Code', value: 100 },
	{ type: 'Error-Code', value: 200 },
// duplicate causes 'never' to be argument type
        { type: 'Error-Code', value: 200 },
])

📃 Motivating Example

Simplified example:
Lets say you are creating DSL/Lib that often uses Tuples with object Literals and you want to make more extensive type checks.
The current solution is to use 'as const' after the argument.

This sadly has some issues:

• not really enforceable even though you really want check every single time when the function is used
• repeated boilerplate code that uglifies the code quite a bit
• really confusing for users that have a little knowledge of TS, and you just wont them to fill in data

It would be great if this responsibility could be optionally redirected to DSL/lib creators, so that Type params that are always meant to be used with Tuples of literal values like object literals, would be marked as such by them.

Following simple example illustrates the problem - I want to check for duplicate entries in sample DSL and must always use 'as const' for proper type checks.

// Checks tuple for duplicates - this will fail to work correctly without 'as const'
type Unique<Tuple extends any[]> = ...

it would be great if I could specify 'as const' for Tuple type param
const test = <Tuple extends Array<any>>(data: Unique<Tuple>) => {}

test([
	{ type: 'Error-Code', value: 100 },
	{ type: 'Error-Code', value: 200 },
// here 'as const' must be specified to work, which is inconvenient
] as const)

💻 Use Cases

1. What do you want to use this for?
   DSLs and libs that use tuples as function arguments often
2. What shortcomings exist with current approaches?
   Forcing users of libs/DSLs to write 'as const' every time they want to have more powerful typechecks on tuples with literals/object literals
3. What workarounds are you using in the meantime?
   Using 'as const' is the current workaround