Is Copy on enums OK?

[simonbuchan]

@H2CO3

I don't understand what you mean by this. Can you elaborate?

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 {}

[scottmcm]

@simonbuchan

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 {}

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

[simonbuchan]

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.

[H2CO3]

@simonbuchan

In any case, a Copy type very much seems like it has no business with mut methods, semantically.

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.