Accept array and unknown as FinalResult

[welovej]

Hi team,

We have a question regarding how FinalResult is expected to be handled for array and unknown result types in typespec.

We met this in TypeSpec migration for service web (appservice) :

Swagger Link:

Unkown : corresponds to
"schema": { "type": "object" }

Array : corresponds to
"schema": { "type": "array", "items": { "$ref": "#/definitions/NetworkTrace" }

Playground

Problem:

When FinalResult is added directly, it results in an error like:

Argument of type 'xxxx' is not assignable to parameter of type '{} | void'

Checklist

• Follow our Code of Conduct
• 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
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[markcowl]

This is a compilation time constraint error, because the LRO APIs only accept models (or nothing) for final result, and this is also enforced by templates and decorators that provide lro metadata.

Generally, this is what we want to enforce for new APIs, but we can relax the constraint. The question is:

• Do we want to relax the constraint in general (I would say yes)
• Do we want to relax the constraint back to the operation templates, or do we want to allow this only for legacy APIs (so that we can enforce a model constraint in templates, but allow specifying a custom header with a relaxed constraint). Not sure here, it may just make sense to relax the constraint completely for some templates (Action) and not others (PUT).

[pshao25]

It seems we don't have constraint on response like we could do

createOrUpdate is ArmResourceCreateOrReplaceAsync<Employee,
  Response = ArmResponse<unknown>>;

I think we should keep consistence between the type of response and the type of final result.