Dysfunctional Options Pattern in Go

The problem with options in non-ML languages is that invalid state is unrepresentable[1]. E.g, in Java Option<Integer> can either be null, empty, some with null and some with a number.

To solve this problem, a language have to disallow null/nil as a bottom type and provide nice syntax to initialize types with optional types.

[1]: https://geeklaunch.io/blog/make-invalid-states-unrepresentab...

I like this write up. Nicely done! One think I have enjoyed doing is using named parameters as the options, but it does require a second struct only for the option parts:

    NewObject(
      required1, 
      required2, 
      &ObjectOptions{
        Option1: “foo”,
        // Option2 skipped
        Option3: “bar”,
    })

I can see the merits of both (two structs is tedious, for sure), but I wanted to share in case others had thoughts or alternate ideas!

Isn’t this just the builder pattern without Build()?

What are the downsides of just adding new methods on the `Config` structure?

    func (c *Config) WithFizz(...) {...}

    func (c *Config) WithBazz(...) {...}

Looks cleaner and simpler. I like this pattern!