feat.: ability for projects like OpenAI to customize anonymous models

[trrwilson]

Clear and concise description of the problem

OpenAI's API specification has a plethora of anonymous models -- in-line objects and other constructs defined within the structure of top-level named type.

Concrete example: the 'code_interpreter' property, as anonymously defined within a 'tool_resources' property that in turn is part of the 'CreateAssistantRequest' component schema.

Many of these end up with... "human-unfriendly" emitter-generated names (speaking to .NET here), owing to being nested many layers deep -- exhibit A, RunStepDeltaStepDetailsToolCallsCodeObjectCodeInterpreterOutputsObject (a real emitted name, further concatenated for things like UnknownRunStepDeltaStepDetailsToolCallsCodeObjectCodeInterpreterOutputsObject.cs.

Problems include:

• It's quite arduous to work with these names during development and maintain them, e.g. avoiding confusion of the above with the very different UnknownRunStepDetailsToolCallsCodeObjectCodeInterpreterOutputsObject.cs
• Without a name to anchor to, we're forced to use in-code-only customizations, even if it's just a rename -- we've resorted to having big "Generator Stub" files, often including things like this line that only exists to change the name of RunStepDetailsToolCallsCodeObjectCodeInterpreterOutputsObject to RunStepCodeInterpreterOutput.

Enter the request: It would be nice to be able to rename these directly in .tsp with something like the following.

Using this as the tsp

//main.tsp
model Foo {
  bar: {
    baz: {
      x: int;
    }
  }
}

We could name both the bar and baz model like this

//client.tsp
@@clientName(Foo.bar, "MyBarName", "csharp", true);
@@clientName(Foo.bar.baz, "MyBazName", "csharp", true);

The clientName decorator would take a new parameter to indicate if it is targeting the anonymous model resulting from the property that is passed in or false (the default) if it is targeting the property itself just like before.

Checklist

• [X] Follow our Code of Conduct
• [X] Check that this issue is about the Azure libraries for typespec. For feature request in the typespec language or core libraries file it in the TypeSpec repo
• [X] Read the docs.
• [X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[m-nash]

One item for additional context.

• The naming of anon models is handled in TCGC so all languages will get the same name RunStepDeltaStepDetailsToolCallsCodeObjectCodeInterpreterOutputsObject so its not just a .NET issue.

Another option we can consider here is if tsp has something like Foo.bar.baz._model where we could directly target the anonymous object. This would be better for 2 reasons.

1. We don't need an extra parameter on all of our decorators
2. It will create the opportunity to give IntelliSense compilation errors if you try to attach to something that isn't an anonymous object such as Foo.bar.baz.x.

[allenjzhang]

::type can be used to reference the anonymous types and its properties. Here using @doc as example

model Foo {
  bar: {
    baz: {
      x: int32;
    };
  };
}

@@doc(Foo.bar, "MyBarName");
@@doc(Foo.bar::type.baz::type.x, "MyBazName");