I seem to remember seeing here or on Twitter someone saying that “if a compileror borrowck error message is confusing or doesn’t help resolve your problem, it’s a bug and we should address it.” But I lost where the right venue is to show examples.
I ran into a case today where I found a pair of suggested remedies that leads to a cycle of adding or removing references. (Basically, RangeInclusive doesn’t implement Copy, leading to a move when that range is iterated upon in an inner loop. The suggestion is to borrow the iterator; but the &RangeInclusive doesn’t implement Iterator, and the recommended change leads to a suggestion to remove the previously-suggested borrow.)
The proper answer appears to be here: https://stackoverflow.com/questions/43416914/why-doesnt-opsranget-implement-copy-even-if-t-is-copy
While I hate the ergonomics and sloppiness, simply adding .clone() in the inner loop resolved the problem in one shot.
I suppose an error message that recognized the potential for this pair of conflicting recommendations and that pointed out the meta-issue would be better.
Related: the Vec API signature works fine in a similar method (which permits discontiguous values for iterating through an array), leading me to wonder what the most efficient way to specify a contiguous range that is not Copy-able? Is .clone() the best choice?
Here’s a playground with some comments about the cycle: