type restriction no longer respected with indirect call involving const enum with number values

[taozhou-glean]

🔎 Search Terms

const enum

🕗 Version & Regression Information

not sure, i think it has been like this for a long time, still present in latest version 5.7.2

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.7.3#code/KYDwDg9gTgLgBAYwgOwM72MgrgWzgFWHTgG8AoOOAQTgF44BmABiYBoK4AhOuARgCYGZAL5kySNPBhEYAMWQ8AFAEMAXARkBKOgD44ysdPTzFhdADoqmsQHobcYFCjR9qB+GAJpAEzJG5yIr81uIoxP4AksjeAJZQnjAAwsoANilKanDYOABGjtq0ev4mytp2cDHwqAAWEFgp3g5OLtWOwK5wAO7AaWJk5SmVjqlwMACeYMBkoJCwoxPtZjAAMkNQqfgLPMxMcAA+fIKhkqMy8vwZ6kur0uspm5MFegZ+Z8j8pjKWIeWOzlAdGYJYC+YrvIIhCThGRRWLxLzJNIXegqdTZPJQJ6nYzg0qUX7NAHKNxArwgshAA

💻 Code

export const enum Test {
  A = 300,
  B = 123
}

const testFn = (a: Test) => a

testFn(Test.A)

// error as expected
testFn(2)

const testIndirectCall = (a: number) => testFn(a) // it should error here as well


// literal type
export type TestLiteralType = 300 | 123
const testFn2 = (a: TestLiteralType) => a

testFn2(Test.A)

// error as expected
testFn2(2)

const testIndirectCall2 = (a: number) => testFn2(a)  // error as expected

🙁 Actual behavior

as noted in above

🙂 Expected behavior

as noted in above

Additional information about the issue

No response

[RyanCavanaugh]

number assignable to enum is intentional; see #26362 (comment) and others. When the number is literal and we can see it's out-of-range, that's also an intentional error. The difference in behavior in different inputs is therefore expected.

[taozhou-glean]

i see, thanks