>From my limited experience, I notice two things: 1. I've rarely ever seen the need arise in my limited own experience to copy objects that would like to share their mutex. I would rather consider this to be most of the time a design issue, but I will be happy to stand corrected. The rationale to me in these cases is that the mutex is protecting a set of information closely "locked" to the lock it is protecting it. When do you even copy the information? Surely not while you don't have the lock, but then you end up with a locked copy. Now, if the copies reference the same lock, what does that really mean? You have two copies of the information, yet a single lock? Why then not having a single source of information with a single lock or two sets of information that can develop independently and have their own locks? 2. Due to the way Interfaces work in Go you can define your own Mutex interface and then sync.Mutex will be one implementation of it. (I hope that I didn't miss something here, but that is what immediately came to my mind.)
On Tuesday, November 8, 2022 at 4:55:13 PM UTC+1 xieyu...@gmail.com wrote: > I checked with the issue about how to refer no-copy and the check of > cmd/vet. After checking, I'm curious that why not define mutex as an > interface, as interface always copy like a reference, which means users > don't worry to copy by value and cause an error. > > Design by the interface can always copy like a reference and no need to > mark it as cannot copy. However, we need to provide a default > implementation of the mutex and the construction of mutex is not short and > clean anymore. > > Would like to see how do you think about this confusion. > > Regrads > -- 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/1294c600-2078-46d3-bbad-50e0c80a3a28n%40googlegroups.com.
