3 ms·
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 optimi
by Mawr 5y ago
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/85e7bee19f9f26dfca414b1e9054e429c448b14f https://github.com/golang/go/commit/85e7bee19f9f26dfca414b1e...
- stingraycharles 5y agoI 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.
- morelisp 5y ago> 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.