Remove generic-parameter-count overload tie-breaker in language version 202c

[tangent-vector]

Problem

compareOverloadCandidateSpecificity currently breaks a tie between otherwise-equivalent applicable generic candidates by comparing their required generic-parameter counts. In practice, the candidate with fewer required generic parameters wins.

That count is not a sound proxy for semantic specificity. For example:

int choose<T : IFloat>(T value)
{
    return 1;
}

__generic<T : __BuiltinFloatingPointType, let N : int>
int choose(vector<T, N> value)
{
    return 2;
}

int result = choose(float3(0.0));

Both candidates are applicable, and their argument conversion costs tie. Slang currently chooses the broad T : IFloat overload because it has one required generic parameter while the structurally narrower vector<T, N> overload has two. The parameter count has caused resolution to select the candidate that is less specific for this call by the criterion the source comment says we ultimately want: applicability of one candidate implying applicability of the other.

There is also an implementation/comment discrepancy worth resolving. The comment says that a candidate with more generic parameters is preferred, but return leftSpecCount - rightSpecCount (where a negative result means the left candidate is better) produces the observed preference for fewer parameters.

Proposed change

For language version 202c, remove the generic-parameter-count comparison from compareOverloadCandidateSpecificity. If no other principled rule distinguishes two applicable candidates, diagnose ambiguity instead of silently selecting one based on this unrelated scalar count.

Preserve the existing behavior for older language versions because changing which overload is selected, or turning a previously resolved call into an ambiguity, is source-breaking.

This is deliberately narrower than the larger work Slang needs for semantic partial ordering of overload candidates. A future implementation should compare applicability/constraint implication and actual specialized parameter shapes. Removing the count heuristic does not solve that larger problem, but in 202c it can stop this heuristic from making actively misleading choices in the meantime.

Why changing the direction is insufficient

Either direction can produce the desired answer only by coincidence. The source already gives this example:

int doThing<T>(vector<T, 3> value);
int doThing<T, let N : int>(vector<T, N> value);

For a float3 argument, today's preference for fewer generic parameters selects vector<T, 3>, which is the desirable result. But that result follows from the fixed-size overload accepting a strict subset of the values accepted by the variable-size overload; parameter count merely happens to correlate with the real relationship. Reversing the count rule would break this case while helping the IFloat/vector example. Retaining today's direction does the opposite.

I have not identified a category where generic-parameter count itself establishes a valid specificity relationship. When the rule gets the desired answer, a structural or constraint-based rule appears to be the actual justification.

Spike results

As a narrow experiment, removing only this comparison had the expected local behavior:

• The IFloat/vector<T, N> example became ambiguous rather than selecting the broad overload.
• Adding [OverloadRank(1)] to the shaped overload then resolved the tie in its favor, because the count heuristic no longer returned first.
• The core module rebuilt successfully.
• 141 executed generic-related diagnostic subtests passed; 59 unavailable subtests were ignored by the local configuration.
• A before/after sample of 138 generic language-feature files had identical results: 107 passed and 31 failed for unrelated pre-existing reasons.

These results are not evidence that removal has no compatibility impact; the change should still be gated to 202c and tested explicitly in both legacy and 202c modes.

Suggested acceptance criteria

• Legacy language versions preserve the existing tie-break behavior.
• Language version 202c does not use required generic-parameter count to choose between otherwise-tied candidates.
• Tests cover both the harmful IFloat/vector<T, N> case and a case such as vector<T, 3>/vector<T, N> that will remain ambiguous until a principled structural-specificity rule is implemented.
• The implementation comment no longer describes parameter count as a valid stand-in for specificity.

[nv-slang-bot]

Triage — enhancement (202c language-behavior change), P2, frontend / overload resolution

• Status: Triaged; current behavior reproduced on top-of-tree. For the IFloat/vector<T,N> example, master (both legacy default and -std 202c) selects the broad int choose<T : IFloat> overload (emitted return int(1)) — confirming the count heuristic picks the less-specific candidate. Handed to an engineer with a fix briefing.
• Root cause: compareOverloadCandidateSpecificity (source/slang/slang-check-overload.cpp:2214-2219) breaks a conversion-cost tie between applicable generic candidates by comparing required generic-parameter counts (getSpecializedParamCount). The arithmetic leftSpecCount - rightSpecCount in fact prefers fewer parameters (a negative result means "left preferred" per the driver at line 2384), which is the comment/implementation discrepancy noted in the issue and is not a sound specificity signal.
• Recommended fix: Gate the count block behind !isSlang202cOrLater(this) (slang-check-decl.cpp:358; SLANG_LANGUAGE_VERSION_202C verified present on master). Legacy versions keep today's selection; 202c falls through to export/scope/OverloadRank and otherwise diagnoses ambiguity. Rewrite the misleading comment; keep the two TODOs describing the still-desired applicability-based rule (the deferred larger work).
• Blast radius: Narrow. generic-overload-disambiguation.slang uses three one-parameter overloads (equal counts → count block already returns 0; separated by conversion cost), so it is unaffected. Non-generic-vs-generic is separated earlier by conversion cost (kConversionCost_UnconstraintGenericParam) and stays unambiguous — verified on master; the fixer will add an explicit 202c regression test for it.
• Next action: Fixer to implement Approach A gated to 202c, add tests covering both legacy and 202c for the IFloat/vector<T,N> (now-ambiguous), vector<T,3>/vector<T,N> (remains ambiguous), an [OverloadRank]-resolved tie, and the non-generic-vs-generic non-regression. Draft PR to follow.

_{🤖 Generated by an automated Slang coworker — may be inaccurate. A human maintainer should verify.}

[tangent-vector]

The narrow implementation in #12830 exposed an important builtin-module complication, so that PR has been moved back to draft while we reconsider the approach.

The generic-parameter-count rule was introduced in #1259 as part of moving concrete core operations to generic Slang definitions. That provenance appears relevant: the current core and builtin modules still contain overlapping overload families for which this rule participates in disambiguation.

A concrete regression is tests/language-feature/operator-overload/builtin-operator-fastpath-glsl.slang. It imports glsl, whose operator overloads intentionally provide semantics that differ from the core defaults:

• matrix * is algebraic matrix multiplication rather than component-wise multiplication;
• vector == and != return scalar bool values.

The test succeeds under Slang 2026. With the proposed 202c removal, its matrix * and vector ==/!= calls all become ambiguous because no later ranking rule chooses among the overlapping core and GLSL generic candidates.

I also instrumented the skipped count comparison and exercised a hand-written scalar/vector/matrix numeric call matrix plus 605 files from the generic/operator, compute, and HLSL-intrinsic test areas. Most observed builtin overlaps either did not produce a source failure or were resolved by later criteria, but the GLSL case is a direct builtin-module regression and is sufficient to show that simply disabling the rule is not safe as a self-contained change.

The temporary instrumentation was not included in #12830. The open design question is now whether these builtin overload families should be restructured or explicitly ranked first, or whether removing this heuristic needs to wait for a more principled specificity relation.