all: consider using variadic options instead of structs

[vangent]

Currently we are using Options structs everywhere. Should we use self-referential option funcs instead?

https://commandcenter.blogspot.com/2014/01/self-referential-functions-and-design.html

[jba]

No; there are many problems with that idea. Here's a list Ross and I compiled a while back:

• Options can be hard to discover. While functions that return the option type are grouped under the type, other ways of defining options are not apparent from the godoc.

• Options bloat a package's API surface.

• Options pollute the namespace (or require verbose names).

• Options bloat the codebase. Most new options require a new type and two functions. (Assuming the option style we've adopted for the cloud.google.com/go packages, where we define and return an unexported type for the option rather than returning an anonymous function.)

• Options have ambiguous properties with respect to ordering. Does order matter, what if you specify the same option twice, etc.

I'd only use functional options if it they were rarely needed, and only one function in the package could use them.

[nhooyr]

Thoughts on a pointer vs a value options structure? I'm liking value options structures right now because then its immediately clear what this extra parameter is for versus nil which masks that.

You also don't need to think about whether there is a difference between nil and the zero value.

[jba]

In cases where the options are infrequently used, it's too much of a burden to write pkgname.Options{} for every call.