Skip to content

Cannot use const string in enum when it's type is specified explicitly #57199

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
undsoft opened this issue Jan 27, 2024 · 5 comments
Closed

Cannot use const string in enum when it's type is specified explicitly #57199

undsoft opened this issue Jan 27, 2024 · 5 comments
Assignees
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@undsoft
Copy link

undsoft commented Jan 27, 2024

πŸ”Ž Search Terms

enum string, enum const

πŸ•— Version & Regression Information

  • This is the behavior in every 5+ version available in Playground.

⏯ Playground Link

https://www.typescriptlang.org/play?#code/MYewdgzgLgBAZgQwJYBsIC4YHIAqBTADyixgF5t8isBuAKFElgHcQAnAawjIsOLtrxgArgFsYARSF5oScDgCeABzwwA3rRgxKscolQQANBq28ATNxYdDtAL5A

πŸ’» Code

const fails: 'Text' = 'Text';
const works = 'Text';

enum QuestionType {
  Text = fails,
  Text2 = works,
}

πŸ™ Actual behavior

When fails is used in enum, there is an error:

Type 'string' is not assignable to type 'number' as required for computed enum member values.(18033)

πŸ™‚ Expected behavior

I can use fails, because to me it is equivalent to works.

Additional information about the issue

Related to #29718 ?

@RyanCavanaugh RyanCavanaugh added Working as Intended The behavior described is the intended behavior; this is not a bug and removed Working as Intended The behavior described is the intended behavior; this is not a bug labels Jan 29, 2024
@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Jan 29, 2024
@ahejlsberg
Copy link
Member

Enum members may be initialized by constant expressions that compute string or numeric values. Constant expressions may reference const variables, but only if those variables have no type annotations. When enum member initializers reference variables with type annotations, they're considered non-constants to be computed at run-time. Such computed enum members are restricted to numeric values. See #50528 for the exact rules.

@RyanCavanaugh
Copy link
Member

Constant expressions may reference const variables, but only if those variables have no type annotations

I think this is probably the thing that sounds surprising, but presumably it's to ward off problems like this?

// Correct emit is ... ?
const fails: number | 'Text' = 'Text';

@ahejlsberg
Copy link
Member

but presumably it's to ward off problems like this?

That's one reason, but another is to avoid circularities. Imagine that a type annotation depends on the enum type for which we are in the process of evaluating constant expressions.

@ahejlsberg ahejlsberg added Working as Intended The behavior described is the intended behavior; this is not a bug and removed Needs Investigation This issue needs a team member to investigate its status. labels Jan 30, 2024
@Andarist
Copy link
Contributor

Isn't @RyanCavanaugh argument already somewhat trumped by allowing this in other similar situations like this one?

// input
const one: number | "Text" = "Text";
const two = one;

// dts output
declare const one: number | "Text";
declare const two: "Text";

I also found a confusing error to be reported in a related situation:

const a = E.two; // A member initializer in a enum declaration cannot reference members declared after it, including members defined in other enums.(2651)
const b = `pre${a}`;

const enum E {
  one = "foo",
  two = `${E.one}bar`,
}

The location of the error seems to be wrong. It mentions a member initializer but the error node is completely different. On top of that, the referenced enum member doesn't depend on any member declared after it.

This problem goes away if we remove const b completely or if we annotate const a with E.two or similar.

@typescript-bot
Copy link
Collaborator

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@typescript-bot typescript-bot closed this as not planned Won't fix, can't repro, duplicate, stale Feb 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

5 participants