OpenAPI Emitter: Allow string type emit from int64

[mascii]

Clear and concise description of the problem

I defined an int64 field in .tsp file and output openapi.yaml, which outputs type: integer in the corresponding field.

In other tools, int64 fields may be output as type: string. For example: https://github.com/grpc-ecosystem/grpc-gateway/blob/cfeed71cd584c65b297d53b02143cd9012b13070/protoc-gen-openapiv2/internal/genopenapi/template.go#L71-L74

Similar to issue #2367, we propose that int64-strategy option be used to switch output.
type: integer is often treated as number type in JavaScript, but number type is not as precise as int64; so this requires a way to represent these values accurately.

Checklist

• Follow our Code of Conduct
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[timotheeguerin]

I would recommend using @encode for this Playground example. The problem with having an emitter option for this is that now openapi3 doesn't produce the same over the wire format as another emitter

[bterlson]

I implemented exactly that switch in the JSON Schema emitter, but I have come to regret it. It's important that you can read a spec and understand that spec's representation across myriad wire formats. When you have compiler flags that alter wire shapes, it breaks that reasoning, because it might be either depending on how the spec consumer decides to compile it. A consequence of that is what Tim mentions, where the openapi3 emit and some other emit (say, REST client emitter) won't agree on a wire shape. In general, it's a recipe for interop bugs within the TypeSpec ecosystem, something we want to avoid if possible.

+1 for using @encode, let us know if that works for you!

[mascii]

I understood why we should not make an emitter option.

On the Playground example, a scalar named int64AsString is defined:

@encode("int64", string)
scalar int64AsString extends int64;

I wanted to define a decorator @int64AsString rather than scalar, so I produced it as a TypeSpec library:
https://www.npmjs.com/package/typespec-decorator-int64-as-string

model Foo {
  @int64AsString // equivalent to `@encode("int64", string)`, not applicable for other than int64 fields
  id: int64;
}

Thank you very much for your thoughtful response!