3 ms·
This feels like it should ideally be something public in the structs package so anyone can leverage it, not just a specially blessed internal thing for the sync
by CamouflagedKiwi 2mo ago
This feels like it should ideally be something public in the structs package so anyone can leverage it, not just a specially blessed internal thing for the sync package.
- 0x696C6961 2mo agohttps://github.com/golang/go/issues/70811 https://github.com/golang/go/issues/70811 Go moves slowly
- wbl 2mo agoYou can very easily define one yourself.
- kbolino 2mo agoYou can exploit the mechanism described in the article yourself, but it's already changed once in the past and is not part of any compatibility guarantee. As with structs.HostLayout, a blessed structs.NoCopy in the standard library could guarantee that it works forever. I think the bigger issue remains that it doesn't actually do anything in the language (but, then again, neither does structs.HostLayout--yet).
- ape4 2mo agoI agree, its a nice piece of semantics to be added to a struct
- advisedwang 2mo agoIt's not a specially blessed type. As the article says, anything that implements sync.Locker acts like this.