Question: why making a copy rather than passing the derefrenced value directly?

[knbr13]

https://github.com/alexedwards/flow/blob/1828f587dbe5c8a465ca74250f696e1d51f89f79/flow.go#L161C1-L164C2

Hello Mr. Edwards, hope you are doing well!

func (m *Mux) Group(fn func(*Mux)) {
    mm := *m
    fn(&mm)
}

I wonder why making a copy of m and then passing the address of the newly created copy to the function, isn't better to update the function declaration to accept Mux instead of *Mux and passing the dereferenced value of m?

func (m *Mux) Group(fn func(Mux)) {
    fn(*m)
}

Comparison

The functionality will remain the same. The differences between them are:

• in the current implementation, a copy of m is created, then a copy of the address will be created, and the (*Mux).Group function contains 2 lines of code.
• in the proposed implementation, a copy of m will be created, and the (*Mux).Group contains only 1 line of code.

[alexedwards]

That's a nice suggestion, and thanks for the question. Like you say, it would be less code in Flow and achieve the same result.

Ultimately I don't think it's a big difference --- with your suggestion the Go compiler will need to 'rewrite' the code to take the address of Mux when calling any of any methods on it within the group, so it all ends up being basically the same operations in the compiled code in end.

Making the change would be a backwards-incompatible change to the public API, which I would prefer to avoid unless there is a major bug or cause for concern,

So it's a nice suggestion, but I think the downsides outweigh the upsides of changing it at this point.

[knbr13]

Aha, got it, I totally agree with you. Thanks!