I agree with what Axel said in the below:
```a lot of people *do* take it as a pretty hard rule. Not as hard as a
compilation error or a vet failure, but still in a way that they think it
is generally agreed that it should never be done. ```
The way I read the https://go.dev/wiki/CodeReviewCom
On Wed, 9 Oct 2024 at 09:54, Ken Lee wrote:
> So can I say that, if I'm not writing concurrency code, it's acceptable
> for me to mix pointer and value receiver?
>
Note that you can't really know, if your users use concurrency or not. And
I still maintain, that concurrency is - mostly - a red he
On Wed, 9 Oct 2024 at 10:42, 'Brian Candler' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> On Tuesday 8 October 2024 at 07:37:25 UTC+1 Axel Wagner wrote:
>
> the only one on the "mixing receiver kinds is sometimes necessary, so we
> shouldn't caution against it" side of the table
>
>
>
On Tuesday 8 October 2024 at 07:37:25 UTC+1 Axel Wagner wrote:
the only one on the "mixing receiver kinds is sometimes necessary, so we
shouldn't caution against it" side of the table
To me this sounds like a false dichotomy. It can be good general
good-practice advice to avoid mixing pointer
So can I say that, if I'm not writing concurrency code, it's acceptable for
me to mix pointer and value receiver? I find that like what @Axel said, I
think there's some struct in STD Lib doing this too? case in point, Time
struct in "time" package.
On Tuesday 8 October 2024 at 10:29:09 pm UTC+8
Just to clarify: From what I can tell, I am (in this revival of the thread)
the only one on the "mixing receiver kinds is sometimes necessary, so we
shouldn't caution against it" side of the table and indeed opened it. As
such, I'm already on the back foot. I tried to at least acknowledge the
argum
You are trying to prove something nobody actually doubted. Meanwhile, you
seem to be aggressively ignoring what I actually wrote. I find that pretty
rude.
On Tue, 8 Oct 2024 at 01:15, robert engels wrote:
> Here is a slightly easier version to see the race between the mutation and
> the copy for
Here is a slightly easier version to see the race between the mutation and the
copy for the value method:
package main
import (
"log"
"sync"
)
type S struct {
lock *sync.Mutex
index int
values [128]int
}
func (s *S) mutate() {
s.lock.Lock();
defer s.lock.Unlock();
I wrote a simple test. Sure enough it fails, and it reports a data race.
package main
import (
"log"
"sync"
)
type S struct {
sync.Mutex
index int
values [128]int
}
func (s *S) mutate() {
s.Lock();
defer s.Unlock();
s.index++;
for i:=0; i< 128; i++ {
