I actually thought about it and your way is strictly better, as it supports CAS (if all interface types involved do), which the pointer-method doesn't.
On Tue, Nov 16, 2021 at 5:16 PM Stephen Illingworth < stephen.illingwo...@gmail.com> wrote: > > How about just a 'container' type for the interface. >>> >>> https://play.golang.org/p/WSXVjVHj1Ya >>> >> >>> For what I need, that does the job nicely. The type being stored in the >>> atomic.Value isn't changing so it satisfies the atomic.Value constraints >>> but I have the flexibility of the contained type being able to change. Any >>> pitfalls with this? >>> >> >> No, that should work fine. Though I'm not sure about "just", it requires >> an extra type but leads to exactly the same memory layout and everything. >> But yeah, if you prefer that, it's completely fine. >> > > I'm happy with it. It feels reasonably clean and there are no special > conditions. Although I should refactor the code so that I don't need > atomics at all and communicate over channels. But this just happens to be > how the code has developed. > > Thanks for the help. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/e58cb004-423a-4d8c-a652-c43eb6556723n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/e58cb004-423a-4d8c-a652-c43eb6556723n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGMMRjPa%3DwUvrOxFwKGgCZmS9fKbwUS4Vstg2iiNbFZUg%40mail.gmail.com.
