Hacker News Reader

Whether a pointer is bad for performance in this case seems hard to tell a priori. There are also performance advantages if Optional packs nicely.

View on HN

It is just an assumption on my part, I figure that the cost of pointer chasing is generally going to outweigh any disadvantages. It can also help enable optimizations, for example slices and maps that do not contain pointers do not get scanned by the GC ([1]).

[1]: https://github.com/golang/go/commit/85e7bee19f9f26dfca414b1e...

I fully agree with your approach. The important thing is that the user now has the choice to use a pointer or not: they can always use a pointer to the optional if they want to use pointers.

Pointers to pointers are generally something you try to avoid if possible.

> the user now has the choice to use a pointer or not

But any benefits of the packing are gone whether I make a pointer or not.

And either way, no nested pointers are involved. We’re not taking pointers to options in either case.

Agreed on performance being in the air. Tbh, I like the non-pointer option because using a pointer was causing the implementation to feel a bit weird. This cleans up a bit of the handling that was annoying (for example in the old implementation Make(&"something") didn't work because you can't reference a constant without first making a variable.

Reply on news.ycombinator.com