Methods in M.W.AI.Generative.ILanguageModelX interfaces missing unique overload attributes

[riverar]

Describe the bug

When projecting Microsoft.Windows.AI.Generative.ILanguageModelX interfaces, methods with identical names (such as GenerateResponseAsync) lack unique Overload attributes. All methods across an interface inheritance hierarchy must have distinct projected names in languages that do not support overloading.

internal interface ILanguageModel
{
	[MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]
	IAsyncOperation<LanguageModelResponse> GenerateResponseAsync(...);
	// ...
}

internal interface ILanguageModel5
{
	[MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]
	[Overload("GenerateResponseAsync")]
	IAsyncOperation<LanguageModelResponse> GenerateResponseAsync(...);
	// ...
}

Steps to reproduce the bug

N/A

Expected behavior

No response

Screenshots

No response

NuGet package version

Windows App SDK 1.7 Experimental 3: 1.7.250127003-experimental3

Packaging type

No response

Windows version

Insider Build (xxxxx)

IDE

No response

Additional context

No response

[connorMicrosoft]

We've acknowledged this Issue and will track it as a Feature Request. Thanks for your feedback!

[connorMicrosoft]

riverar, can you share more about the scenario you're trying to enable here? Why do you need methods with identical names?

[riverar]

Hey @connorMicrosoft,

The issue isn't that I'm trying to create methods with identical names. Rather, this is about proper projection of new Windows Runtime APIs into languages that don't support method overloading. This is basic stuff.

When the Windows Runtime projects interfaces like Microsoft.Windows.AI.Generative.ILanguageModelX into languages without overloading support (such as Rust, JavaScript, or Python), methods with identical names across an inheritance hierarchy need to be given unique projected names via the [Overload("Name")] attribute.

(Story: As a developer, I'd like to use your APIs with something other than C#+WASDK.)

It was my intention to provide feedback as early as possible to influence the design of this API before it went into preview and production.

[riverar]

@DrusTheAxe Can we cut to the chase here? Are we stuck with this API design because you guys already shipped it and iterated on it internally?

[kennykerr]

This is a bug being tracked internally. Thanks for your patience.

https://dev.azure.com/microsoft/OS/_workitems/edit/56397011