Skip to content

as const breaks intra expression inferenceΒ #62220

@Andarist

Description

@Andarist

πŸ”Ž Search Terms

const context expression assertion inference type parameter

πŸ•— Version & Regression Information

  • This is the behavior in every version I tried

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=6.0.0-dev.20250806#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXwxAGcMAeAFQBp4ARAPgApYBzALngG8AoeeLVAA7IM7GgG4e8ATBzBkYEOyYw2tAJTwAvHXjkJvMHiLIAtovjLV5DdvipTAIxAwJAXzWiJXQ6hLwHMgDWIPiaBMQYDNy8-EIi8ACMAAxJlJLSsvLmljY6LAB0GDgAyhgw-MwMamkGRqbZLLnwBRAhzBgAFmmuzUTwPiRqXgMY8ADuODCBFVrhJFGSscLsyanpMnIKSo1aeSqFJWUVVTX9dWbbKk0tbZ3dQ1xAA

πŸ’» Code

declare function test<T, D>(arg: {
  input: D;
  produce: (arg: D) => T;
  consume: (arg: T) => number;
}): D;

const broken = test({
  input: 100,
  produce: (arg) => arg.toString(), // 'arg' is of type 'unknown'.(18046)
  consume: (arg) => arg.length,
} as const);

const working = test({
  input: 100,
  produce: (arg) => arg.toString(), // `arg` inferred as `number`
  consume: (arg) => arg.length,
});

πŸ™ Actual behavior

as const is the only difference between those two and its presence breaks assigned parameter type in produce

πŸ™‚ Expected behavior

I think as const should not impact inference this way and both should be inferred just OK. It's just that the broken case should infer 100 instead of number for the D type parameter

Additional information about the issue

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions