Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a NoOptionalPointers config option for gocode types gen #100

Closed
sdboyer opened this issue Jan 13, 2023 · 0 comments
Closed

Add a NoOptionalPointers config option for gocode types gen #100

sdboyer opened this issue Jan 13, 2023 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@sdboyer
Copy link
Contributor

sdboyer commented Jan 13, 2023

Currently, optional fields in a schema result in Go code with pointer types, as that's the only means Go has for actually expressing field optionality.

While technically correct, this is very non-ergonomic Go. While it pains me to do it as it introduces an ambiguity (see grafana/grok#1), we should at least add an option to gocode.TypeConfigOpenAPI, say NoOptionalPointers, which causes optional fields not to be generated with pointers.

Additionally, we should just never render slice and map types with pointers. It's redundant.

I wrote this little thing a while ago to fix that, though never committed it:

// MapSliceDepointerizer returns an AST manipulator that removes redundant
// pointer indirection from all map and slice types.
func MapSliceDepointerizer() astutil.ApplyFunc{
       return func(c *astutil.Cursor) bool {
               switch x := c.Node().(type) {
               case *ast.Field:
                       if s, is := x.Type.(*ast.StarExpr); is {
                               switch deref := depoint(s).(type) {
                               case *ast.ArrayType, *ast.MapType:
                                       x.Type = deref
                               }
                       }
               }
               return true
       }
}

It will need to be shifted to dst, but i suspect it's a good basis for handling both of these problems at once.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants