Is Copy on enums OK?

help
21

I read it is "there should be a warning for calling a &mut method on a temporary" (where a temporary is a value dropped at the end of the current expression, just to be explicit)

I think it would be a bit too noisy as a warning, but it might be a good default clippy. You generally don't want to mutate temporaries, most builders want to at least support moving ownership down the call chain so the final build call can take from the builder for example. Maybe nonstandard lock guards' methods would want this? (The standard ones can directly go to derefmut, which has clear semantics)

In any case, a Copy type very much seems like it has no business with mut methods, semantically. The exclusion implied by the mut has no actual effect and can be defeated by a simple wrapping {}

22

I think this is overstated. I very much want get_mut to work on [u32; 10] even though it's Copy, for example.

1 Like
23

True, that's a great counter example, but if I can put up a pale defense of myself, Copy arrays are weird in a few ways.

24

My point is exactly that it's not clearly/generally the case. Even implicit &mut self needs to be allowed if you want to implement something as trivial as AddAssign on primitive numeric types.

Incidentally, at $JOB, I wrote some generic signal processing code that needed to accumulate values of a generic type (for computing convolutions and related operations), and the best design for that was passing a &mut to the appropriate internal method of the filter data structure.

25

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.