Fix confusing keywords "as const" and introduce "valueof"

[kadun13nindi12]

🔍 Search Terms

as const, valueof

✅ 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

Title: Feature Request: Introduce valueof utility type and clarify as const semantics

Summary

Two related ergonomics improvements:

1. Add a built-in valueof utility type
2. Consider aliasing or renaming as const to better reflect what it actually does

Problem

1. No valueof utility type

Getting a union of an object's values currently requires a non-obvious incantation:

const HTTP_METHODS = { get: 'GET', post: 'POST' } as const;
type HttpMethod = typeof HTTP_METHODS[keyof typeof HTTP_METHODS];
// 'GET' | 'POST'

This is one of the first things developers need and one of the hardest patterns to discover or remember. A valueof utility type would make this trivial:

type HttpMethod = valueof<typeof HTTP_METHODS>;
// 'GET' | 'POST'

keyof exists for keys — valueof should exist for values. The asymmetry is confusing.

2. as const is a misleading name

as const does two things:

• Makes all properties readonly
• Narrows types to their literal values (e.g. string → 'GET')

The name as const suggests it relates to the const keyword, but const variables are already const. What as const actually does is narrow types to literals and make properties readonly. A name like as readonly or as literal would be far more self-documenting.

Suggested Solution

1. Introduce valueof<T> as a built-in utility type equivalent to T[keyof T]
2. Consider introducing as readonly as an alias or replacement for as const

Why This Matters

These two concepts (as const + keyof typeof) are among the most commonly googled TypeScript patterns by developers at all experience levels. The current API has a steep discoverability cliff that a simple addition would eliminate.

📃 Motivating Example

A developer wants a union of all values in a config object:

const HTTP_METHODS = { get: 'GET', post: 'POST', put: 'PUT', delete: 'DELETE' } as const;

// Current — non-obvious, hard to discover:
type HttpMethod = typeof HTTP_METHODS[keyof typeof HTTP_METHODS];

// Proposed — intuitive, mirrors keyof - without need of "as const" before:
type HttpMethod = valueof;

"as const" could remain for the second intended purpose - to make all properties readonly and preferably also renamed to "as readonly"

💻 Use Cases

1. Deriving union types from config/lookup objects (HTTP methods, routes, status codes, event names)
2. Creating enums-without-enums — const objects with derived value unions
3. Any time a developer needs "give me a type that can be any value in this object"

This pattern is so common it appears in nearly every TypeScript codebase, yet it requires knowledge of three separate concepts (as const, typeof, keyof) that beginners and intermediate developers consistently struggle to combine correctly.

[nmain]

This isn't a request to add a new utility type

Isn't that what valueof is? type valueof<T> = T[keyof T]; satisfies your requirements and can be implemented in userspace.

[MartinJohns]

Duplicate of #37642.

[jcalz]

Not a TS team member, just an interested community member.

---

This is two independent requests filed in a single github issue. To the extent that these requests are valid, they should be filed in separate issues. But:

• People have already commented about valueof: that feature request already exists, and will likely never be implemented as it's the equivalent of a utility type since you can build it yourself. So this part of the request is just a duplicate.

• Changing as const to as readonly is interesting, but the feature you're trying to change is 6 years old. It seems the time for such a change has long since past. If as const were to stop working it would be a big breaking change in TypeScript for what looks like very little benefit... you're only helping people who mostly don't write TypeScript code, at the expense of those who do. Or if it's just an alias and both forms work, then it's very similar to asking for a utility type. You could write an asReadonly function like

  function asReadonly<const T>(t: T): T { return t }

  and include it in a library for new TS users, without requiring a change to the language itself.

[Mudloop]

Not a TS team member, just an interested community member.

This is two independent requests filed in a single github issue. To the extent that these requests are valid, they should be filed in separate issues. But:

• People have already commented about valueof: that feature request already exists, and will likely never be implemented as it's the equivalent of a utility type since you can build it yourself. So this part of the request is just a duplicate.

• Changing as const to as readonly is interesting, but the feature you're trying to change is 6 years old. It seems the time for such a change has long since past. If as const were to stop working it would be a big breaking change in TypeScript for what looks like very little benefit... you're only helping people who mostly don't write TypeScript code, at the expense of those who do. Or if it's just an alias and both forms work, then it's very similar to asking for a utility type. You could write an asReadonly function like
  function asReadonly(t: T): T { return t }

  and include it in a library for new TS users, without requiring a change to the language itself.

I mostly agree, but would like to note two things :

• writing utility types is ok, but I often sketch out things in the playground and end up having to find and copy paste the same things over and over again, and then later reorganise things again. So just because something is possible in userspace doesn't mean it can't be useful to include things in the language itself. As an example - things like figuring out which of two numbers is larger can be done in userspace but require elaborate types that will always be quite expensive (plus many pitfalls like dealing with unions).
• I agree that as const shouldn't change - introducing an alias that does the same thing will just confuse people more (and obviously a breaking change isn't happening). But as const has two functions as OP noted, and it might be useful to have separate keywords for both. I may want to indicate that a given type should be narrow, without introducing readonly modifiers that I tend to strip out afterwards (not that I mind the immutability, I just like to keep the visual types leaner, just preference).

[nmain]

So just because something is possible in userspace doesn't mean it can't be useful to include things in the language itself.

This has been discussed and rediscussed many times to the point that there's a FAQ entry in the issue template about it.

[RyanCavanaugh]

Echoing #63557 (comment), neither of these are changes that are aligned with our general principles.