[REQ] [Go] Map integer type without format qualifier to int

Is your feature request related to a problem? Please describe.

Right now, the AbstractGoCodegen.go maps the integer types as:

typeMapping.put("integer", "int32");
typeMapping.put("long", "int64");

With the following minimal example for integer type definitions:

openapi: 3.0.2
info:
  title: Test go integer
  version: 0.0.1
paths:
  /project:
    get:
      responses:
        200:
          description: ok
components:
  schemas:
    Project:
      properties:
        id:
          type: integer
        id_int32:
          type: int32
        id_int64:
          type: int64
      type: object

this is the corresponding model (with go-server generator):

type Project struct {
	Id int32 `json:"id,omitempty"`
	IdInt32 int32 `json:"id_int32,omitempty"`
	IdInt64 int64 `json:"id_int64,omitempty"`
}

So, when the format of the integer type is not specified a int32 variable is generated. This can be annoying as int, int32, int64 are distinctive types in Go. When your code does not care about the exact size and wants to use int (which is idiomatic for indices, length of arrays, etc.) you have to cast manually.

According to Spec the format specifier is optional and gives us the possibility to choose between int32 and int64. Therefore, when not specified, it should be assumed that the primitive type int should be used.

Describe the solution you'd like

Change the type mapping to:

typeMapping.put("integer", "int");
typeMapping.put("long", "int64");

which results in the following output (tested):

type Project struct {
	Id int `json:"id,omitempty"`
	IdInt32 int32 `json:"id_int32,omitempty"`
	IdInt64 int64 `json:"id_int64,omitempty"`
}

Describe alternatives you've considered

Additional context

I'm not 100% sure, if the OpenApi specification requires that an integer without format qualifier should automatically default to an int32 type. As the format specifier is optional I would assume not, but maybe someone can clarify this assumption.

But as the abstract go generator handles checks the type mapping key and values against the built in types the proposed fix above works fine

Start in modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/AbstractGoCodegen.java and inspect the integer type mappings. Generate the minimal OpenAPI example from the issue with the go-server generator, then verify that an unqualified integer produces int while int32 and int64 formats retain their existing Go types.