Fix label names when internalSignature has optional params

[aswinsvijay]

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]

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)

• Read the PR diff and understand the change
• Look at surrounding context in ark/type/fn.ts
• Check the linked issue fn does not infer parameter labels correctly if internalSignature has optional parameters #1614 for context
• Investigate applyElementLabels to understand impact of Required<>
• Submit review

  ^{｜ View workflow run ｜ via Pullfrog ｜ 𝕏}

[pullfrog]

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.

  ^{｜ View workflow run ｜ 𝕏}

[pullfrog]

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.

  ^{｜ View workflow run ｜ 𝕏}

[ssalbdivad]

Verified the fix and added the regression test. Labels are cosmetic but still part of the inferred type, so attest(...).type.toString pins them.

[ssalbdivad]

Thanks @aswinsvijay — merging.

I added the regression test and rebased onto main. Labels looked untestable because they're cosmetic, but they're still part of the inferred type, so attest(...).type.toString pins them exactly.

One note for the future: the declared type's optionality should match the implementation's. fn('string', 'number') says the second argument is required, so an implementation taking (a, b?) describes a call that can't happen — prefer fn('string', 'number?') and let the declared type drive the signature. The test uses that form, since a contextually inferred parameter already labels correctly; it's annotating the optional one that triggers the bug.