modifies-value-receiver: miss modification by setting something in a slice

[ccoVeille]

Somehow related to

• modifies-value-receiver: miss modification by ++/-- #1109
• modifies-value-receiver: miss modification by setting something in a sub structure  #1117

This is not detected

type A struct {
   lst []string
}

func (a A) Foo() {
	a.lst[0] = "whatever"
}

Here we have to assume that lst was populated before calling Foo

[chavacava]

Hi @ccoVeille, could you please elaborate on what the problem is?

The fact that Foo refers to the first position of a potentially not initialized slice? (revive can't do too much about that)
The fact that Foo modifies the content of the slice?

The rule spots assignments to a by value receiver to prevent the error of modifying an "ephemeral" copy of the struct in the belief that the modification is made on the "persistent" version. In the example you provide, the "persistent" slice content is actually modified by Foo

[ccoVeille]

Hi @ccoVeille, could you please elaborate on what the problem is?

The fact that Foo refers to the first position of a potentially not initialized slice? (revive can't do too much about that)

It's not about that

The fact that Foo modifies the content of the slice?

Yes. A slice that is a copy of Foo

The rule spots assignments to a by value receiver to prevent the error of modifying an "ephemeral" copy of the struct in the belief that the modification is made on the "persistent" version.

In the example you provide, the "persistent" slice content is actually modified by Foo

But Foo is passed without a pointer.

So a.lst[0] is not set to "whatever" outside this method.

Please take a look at Incr() method in the example provided on #109

It's the same logic, no?

I mean outside the method the counter is not incremented.

The current code detect if you set a value of the struct and if you return nothing, no?

I might be simply missing something, or maybe everything.

[chavacava]

The slice content is actually modified "globally": https://go.dev/play/p/-K_b2r9wrUm

[ccoVeille]

Indeed, but replacing the value, no.

https://go.dev/play/p/dQMftzHYzT-

I think I faced this once. It looks like very odd, when you face it.