Reserved golang keywords in spec cause errors

[stevenvegt]

I have a type parameter in my spec as follows:

/animal/{type}:
    get:
      summary: Get an animal by type
      parameters:
        - name: type
          in: path
          required: true
          schema:
            type: string

Which resuls in the following server interface:

type ServerInterface interface {
  GetAnimalByType(ctx echo.Context, type string, params GetAnimalByTypeParams) error
}

But as you can see this results in a parameter named type which is a reseverd golang keyword.

Perhaps pre/post fixing all param names can prevent these errors.

[deepmap-marcinr]

There are many cases where this will happen, so I'm thinking of side-stepping the problem by allowing people to specify the Go variable name explicitly via extended properties. You could do something like:

/animal/{type}:
    get:
      summary: Get an animal by type
      parameters:
        - name: type
          x-golang-name: animalType
          in: path
          required: true
          schema:
            type: string

which would yield

type ServerInterface interface {
  GetAnimalByType(ctx echo.Context, animalType string, params GetAnimalByTypeParams) error
}

I'm in the middle of a big project right now, but I'll revisit this sometime soon.

[stevenvegt]

The problem here is that you do not always have control over the spec as it can be created by a third party. Adding language specific tags sounds like a hack.

Postfixing every param with Param for example would also result in an unique non-confilicting string.

If we can think up an elegant solution I'm happy to provide a PR if that helps you.

[deepmap-marcinr]

You're right.

I didn't want to break existing clients, so in the case of parameters which are go keywords, I prefix those with p, so type becomes pType. Non-conflicting names are not prefixed.