Skip to content

Fix label names when internalSignature has optional params#1615

Open
aswinsvijay wants to merge 1 commit intoarktypeio:mainfrom
aswinsvijay:fix-optional-param-labels
Open

Fix label names when internalSignature has optional params#1615
aswinsvijay wants to merge 1 commit intoarktypeio:mainfrom
aswinsvijay:fix-optional-param-labels

Conversation

@aswinsvijay
Copy link
Copy Markdown

@aswinsvijay aswinsvijay commented May 1, 2026

Fixes #1614

  • Code is up-to-date with the main branch
  • You've successfully run pnpm prChecks locally
  • There are new or updated unit tests validating the change

Unsure how this can be tested since tuple labels are not part of the type system.

@pullfrog
Copy link
Copy Markdown
Contributor

pullfrog Bot commented May 1, 2026

Reviewed PR #1615 — approved. The one-line fix correctly wraps Parameters<internalSignature> with Required<> to prevent optional implementation parameters from breaking label inference in applyElementLabels.

Task list (5/5 completed)

Pullfrog  | View workflow run | via Pullfrog𝕏

Copy link
Copy Markdown
Contributor

@pullfrog pullfrog Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed — no issues found.

The fix is correct: Required<Parameters<internalSignature>> ensures the labels tuple passed to applyElementLabels is always fully required, which is the right semantics since parameter optionality in the external signature is determined by distill.In<paramsT> (the first arg), not the implementation's parameter declarations. The recursive [unknown, ...infer labelsTail] destructuring in applyElementLabels can break when the labels tuple has optional elements — this cleanly prevents that.

Pullfrog  | View workflow run𝕏

Copy link
Copy Markdown
Contributor

@pullfrog pullfrog Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed — no issues found.

The fix is correct: Required<Parameters<internalSignature>> ensures the labels tuple passed to applyElementLabels is always fully required, which is the right semantics since parameter optionality in the external signature is determined by distill.In<paramsT> (the first arg), not the implementation's parameter declarations. The recursive [unknown, ...infer labelsTail] destructuring in applyElementLabels can break when the labels tuple has optional elements — this cleanly prevents that.

Pullfrog  | View workflow run𝕏

@aswinsvijay aswinsvijay changed the title fix label names when internalSignature has optional params Fix label names when internalSignature has optional params May 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: To do

Development

Successfully merging this pull request may close these issues.

fn does not infer parameter labels correctly if internalSignature has optional parameters

1 participant