Comparability/type assertion failure when using enums and underlying literals

Mateusz Burzyński (@Andarist)

The regression reported here can be traced back to #53192. The minimal~ repro case for it is this:

enum AutomationMode {
  NONE = "",
  TIME = "time",
  SYSTEM = "system",
  LOCATION = "location",
}

interface ThemePreset {
  id: string;
}

interface Automation {
  mode: AutomationMode;
}

interface UserSettings {
  presets: ThemePreset[];
  automation: Automation;
}

interface ExtensionData {
  settings: UserSettings;
}

export function getMockData(): ExtensionData {
  return {
    settings: {
      presets: [],
      automation: {
        mode: "",
      },
    } as UserSettings,
  }
}

TS playground

Originally posted by Mateusz Burzyński (@Andarist) in #53192 (comment)

Isn't it intentional that string literals are not assignable to string-based enums, even if they match one of the enum members?

It's about comparability and it seems that this type of conversion is valid in such a context, for example, this is OK:

const foo = "" as AutomationMode

Ah, I missed the type assertion as UserSettings so it just looked like an assignability failure, which was expected.

The fix here is to exclude the comparable relation from the optimization in #53192. I will put up a PR.

Navigation Menu

Repository navigation

Comparability/type assertion failure when using enums and underlying literals #53400

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Comparability/type assertion failure when using enums and underlying literals #53400

Description

Activity

fatcerberus commented on Mar 21, 2023

Andarist commented on Mar 21, 2023

fatcerberus commented on Mar 21, 2023

ahejlsberg commented on Mar 21, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions