[Golang] Optional parameters are not optional.

[antihax]

Description

Currently optional parameters generate code with no option to exclude them, making the parameters required.

Swagger-codegen version

master HEAD

Suggestions

1. Use interface{} for optional parameters, except string, with run-time type checking.
2. Use pointers (dangerous due to race conditions: i.e. go func in for loop).
3. Use a map to pass parameters (similar to the Perl version).

I am leaning towards implementing 1 unless there are other suggestions?

[wing328]

@antihax thanks for the feedback. We did have a discussion on that before. From what I recall, it's a bit tricky to implement optional parameters in Go as it does not support optional parameter natively.

Here is the approach taken by Github GO API client (provided by Google):
https://github.com/google/go-github/blob/master/github/activity_star.go#L49-L61
which defines the optional parameters in a struct.

I'm not sure which approach is the best. cc'ing the experts:

cc @guohuang @neilotoole

[antihax]

@wing328 That is a very interesting API. It is using another library (https://github.com/google/go-querystring) to handle the url encoding which states that the "optional parameters" are determined by the following:

The empty values are false, 0, any nil pointer or interface value, any array slice, map, or string of length zero, and any time.Time that returns true for IsZero().

Would these cases be true for Swagger 2.0 optionals or would applying the same logic break from spec? Assuming an integer of 0 is empty sounds a bit scary.

[wing328]

You're right in saying that the Swagger spec does not use the same logic.

Here is another discussion related to Go optional parameters: http://stackoverflow.com/a/13603885/677735

[antihax]

This unfortunately is the same as the google method. Go is like C, an int cannot be nil or null; so in their example:

type Params struct {
  a, b, c int
}
p := &Params{a: 1, c: 9}

Results in a structure of: { a: 1, b: 0, c: 9 }

Thus I am still leaning towards the best option being the use of interface{} which would allow any type and then perform type checking at runtime. The pro is that the API would remain the same, the cons are that developers can trip over a runtime error due to passing the wrong argument type, which would normally be caught at compile time.

Something like this is what I am thinking: https://play.golang.org/p/3Kjab4mUQn

[antihax]

See PR #4306

[NfNitLoop]

What about accepting pointers for optional values? That way, you can pass a nil, or a pointer to a value, to specify whether that value should be specified in the request. Ex:

func foo(optional *int) {
    if optional == nil {
        fmt.Println("No value specified.")
    } else {
        fmt.Println("Got value: ", *optional)
    }
}

This has the advantage that you don't throw away compile-time type checking. And you keep the types in the Go code, if you're reading that to figure out what type you need to pass in to a generated function.

[antihax]

You lose the ability to pass anonymous variables in the function parameters, which is very inconvenient.

func takesAString(s *string) {
	fmt.Printf("%s\n", *s)
}

takesAString("some other string")

results in cannot use "some other string" (type string) as type *string in argument to takesAString

Also easily introduce race conditions. https://play.golang.org/p/43YfkHb_tO

[NfNitLoop]

That's a fair criticism. But it's also easy to work around.

value := "some other string"
takesAString(&value);

A little less convenient, but worth it for the compile-time type checking, IMO. (I don't do a lot of development in Go, though, so maybe doing runtime reflect-y stuff is more idiomatic than I imagine?)