Operator deduplication may miss commutative or symmetric Dot/Cross variants

[matt-edmondson]

Summary

Semantics.SourceGenerators/Generators/QuantitiesGenerator.cs deduplicates emitted operators using simple string keys (e.g. "Dot:{selfType}:{otherType}:{resultType}", "Mul:{a}:{b}"). These keys are not symmetric across operand order, so the generator can emit:

• both A * B and B * A for commutative multiplications
• a Dot(B) on A and another Dot(A) on B whose generated bodies represent the same scalar product

The result is duplicate definitions or — worse — slightly inconsistent ones if metadata changes between sweeps.

Evidence

• QuantitiesGenerator.cs:153-161 and :245-278 build the dedup keys directly from operand order.
• Self-divide is handled as a special case (:161) but no equivalent commutative normalisation exists for cross-dimensional ops.

Suggested next step

• Normalise operand order in dedup keys (e.g. sort the operand type names alphabetically when the relationship is declared commutative).
• Add a generator-level invariant test that compiles a small fixture and asserts no duplicate methods/operators per generated type.

Area / Severity

SourceGenerators · incomplete

[matt-edmondson]

After re-reading the dedup paths in QuantitiesGenerator.CollectAllOperators / CollectAllProducts against dimensions.json, I don't think we have a current-bug-fix here, but the issue's "add a generator-level invariant test" suggestion is still useful.

Why no current bug:

• The * and / keys ({op}:{left}:{right}:{ret}) are intentionally direction-sensitive. For commutative multiplication we want both Mass<T> * Acceleration<T> and Acceleration<T> * Mass<T> to compile, so the generator emits both — each on the appropriate owning type. Two operators with the same key are deduped (AddOp), so re-declaring the same relationship from both ends costs nothing.
• Likewise Dot:{self}:{other}:{result} — A.Dot(B) and B.Dot(A) are emitted as separate methods on the two owning types, never as duplicates on the same type. Same for Cross.
• The op == "/" && left == right short-circuit at line 305 drops the trivial self-divide because PhysicalQuantity already gives us TSelf / TSelf -> TStorage.

What's worth adding (if/when someone picks this up):

1. A snapshot or analyzer-style test that compiles the emitted output and asserts no method/operator is declared twice on the same owner type — locks in the property even if dedup logic changes.
2. Optionally, normalise commutative dedup keys when the relationship is declared from both ends with conflicting result types — currently we'd emit two operators with the same operands but different return types, which is a real metadata bug we'd want to surface as a SEM003.

I'll leave this open for the test/diagnostic-hardening work; not a blocker.

---

Generated by Claude Code