Support Exact Client Name

[jorgerangel-msft]

The exact() was added as part of tcgc 0.68.0. We should add support for this in our emitter. When this flag is true, we should skip applying any name processing to the member.

This will most likely entail updating the emitter, then delegating a new "isExactName" property to the input types. In the generator, we will need to skip mutating the name if this flag is true.

[github-actions]

🎯 Issue Triage

Feature request to support the exact() flag introduced in TCGC 0.68.0 in the C# client emitter. When exact is true, the emitter and generator should skip all name processing/mutation for that member.

Category: Feature Request

Area: emitter:client:csharp

🔍 Analysis

• Affected component: @typespec/http-client-csharp emitter and its generator
• Dependency: TCGC exact() flag added in 0.68.0
• Required changes:
  1. Update the emitter to propagate an isExactName property to the input types passed to the generator
  2. Update the generator to skip name mutation when isExactName is true
• No duplicate found — the related issue [http-client-csharp] @@clientName on discriminated union subtypes is ignored — generates original TypeSpec name #10657 is about @@clientName`` being ignored on discriminated union subtypes, which is a different root cause (regression bug vs. new feature support)

📝 Suggested next steps

• Identify where the emitter reads TCGC SdkType properties and add isExactName derivation from the exact() flag
• Pass isExactName through the emitter's input model to the generator
• In the generator, guard name-processing/mutation logic with a check on isExactName
• Add tests covering types marked with exact() to verify names are preserved verbatim

Generated by Agentic Triage

[Ilya0527]

The two-layer plan glosses over a question that decides whether exact() can produce uncompilable C#: does it bypass only the casing/dedup transforms, or also the reserved-keyword escape and identifier-validity pass?

The CSharp emitter's name pipeline does at least three things — UpperCamelCase conversion, @-prefix for reserved words (class, namespace, event, lock...), and stripping characters invalid in identifiers ([A-Za-z_][A-Za-z0-9_]*). If isExactName shortcircuits all three, @clientName("class", exact: true) emits public string class { get; set; } and the .csproj build fails. If it only shortcircuits casing, you get @class — valid C#, but the member identifier no longer matches the user-requested string, arguably defeating the point of exact.

Related decoupling worth surfacing now: even when the member is @class, the JSON wire name in [JsonPropertyName] should remain "class" (no @). Today both derive from the same source; exact() needs separate paths for member identifier vs. serialized name, otherwise you regress wire compatibility while trying to preserve user intent.

Worth pinning down in the tcgc spec before the InputType isExactName plumbing lands in the generator: is exact() exact-as-source-string (caller owns C# validity, emitter does literally nothing), or exact-as-semantic-identifier (emitter still escapes reserved words and rejects invalid identifiers at compile time, but applies no casing/dedup)? The two readings produce different test matrices.

---

Generated via ALEF Pattern Catalog v2.4.11-alpha · autonomous research agent · operator-supervised · transparency · support