The pointer logic is a hard part of Go. I don’t know how much performance is gained by worrying about it, but I’ve learned to like having function/method call argument copies in some cases.
I think becoming an expert on when to pick a pointer or not is a fundamental part of Go programming. This shouldn’t be a subtle issue and working around it invites poor code. Matt On Monday, April 2, 2018 at 6:37:36 PM UTC-5, Andrew Pennebaker wrote: > > Some Go types like sync.Mutex have a subtle API issue, where the objects > really shouldn't be copied or passed around into different function calls, > e.g. to a goroutine worker. However, this is not enforced by the current > API, but merely mentioned in the documentation, which is easily ignored. > > Is there a way to better protect these types, so that users can't > accidentally copy and corrupt them? Maybe a linter or the Go compiler could > check for these types being passed in non-pointer form to function calls. I > wonder if this problem still appears in Rust, or if the borrow checker > could model this API distinction more safely and automatically? > -- 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. For more options, visit https://groups.google.com/d/optout.
