Microsoft/TypeScript

Enum keys not accepted as computed properties if their name is not a valid identifier

Open

#25,083 opened on Jun 20, 2018

View on GitHub
 (3 comments) (0 reactions) (0 assignees)TypeScript (48,455 stars) (6,726 forks)batch import
BugDomain: enumGood First Issue

Description

TypeScript Version: 2.9.2

Search Terms: computed property name

Code

enum Type {
  Foo = 'foo',
  '3x14' = '3x14'
}

type TypeMap = {
  [Type.Foo]: any
  [Type['3x14']]: any
}

Expected behavior: Type['3x14'] to be usable as a computed key in a type definition.

Actual behavior: A computed property name in a type literal must refer to an expression whose type is a literal type or a 'unique symbol' type.

This is the case even for Type.Foo if it's written as Type['Foo'] instead; so it seems there is some early bailout when the bracket operator is involved. For certain key names it may not be possible to write them without resorting to brackets, like a name that starts with a digit.

Playground Link: Link

Contributor guide

Tech stack
typescript
Domain
tooling
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
TypeScript type system basicsUnderstanding of computed properties
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
20
Research direction
The issue involves the TypeScript checker's handling of computed property names in type literals. Look at the code path for checking computed property keys in checkComputedPropertyName or similar functions in src/compiler/checker.ts. The playground link shows the error. The fix likely requires allowing bracket access expressions like Type['3x14'] when they resolve to literal types. Consider the existing logic that allows Type.Foo but not Type['Foo'].