4 ms·

> It's a lot of boilerplate to create something that's not actually immutable How is not actually immutable? How could cfg.opts.name be modified after New() r

> It's a lot of boilerplate to create something that's not actually immutable How is not actually immutable? How could cfg.opts.name be modified after New() returns? > It also makes it harder to figure out which options are available I find it easier, the go tooling helps a lot. For example, all the options are grouped together at https://pkg.go.dev/github.com/go-kit/log/level#Option https://pkg.go.dev/github.com/go-kit/log/level#Option It's also easy to use "Find Usages" in my editor, and filter on return type.

jen20 3y ago
It could be mutated by anything in the package that contains the type. The only thing Go can make truly immutable - as in a compiler error if you try - is a constant primitive. Functional options have some niceties - largely their ability to evolve without breaking changes - but as the GP points out, completely break discoverability with intellisense. Having to do some dance with filtering usage to find the options available is just worse than a static config struct with zero values that are meaningful for anything not set.