Add known downside to mem_replace_with_default: not backwards compatible with 1.39

[jyn514]

Clippy suggests turning mem::swap(a, Default::default()) with mem::take(a). However, mem::take was only stabilized in 1.40 and changing this will break compatibility with older versions. This should be added to # Known problems on the website.

cargo clippy -V: clippy 0.0.212 (4ee1206 2020-02-01)

[tesuji]

Edit: Sorry if my old edit seems to be rude. I dont' mean that.
Clippy is using master to develope to take advance of newer std to suggest
improvements.

If we add version that # known problems for mem::replace, does it mean that we should add it
everywhere else that could also be applied?

If people don't want clippy to warn about mem::take,
they may use the older clippy version (clippy ships with 1.39 in this case)
or ignore that lint with attribute #![allow(clippy::mem_replace_with_default)].

[jyn514]

If I use an older clippy, then I miss out on the bug fixes and lints in the new clippy, most of which are backwards compatible. This is the same reason I use rustc 1.42 to develop but test with 1.37 on CI.

[tesuji]

You could ignore that lint with attribute #![allow(clippy::mem_replace_with_default)]
and add a FIXME to remember to remove it in case of bumping to newer rust version.

[jyn514]

Sure, that's what I plan to do. I just think it should also be mentioned as a potential downside.

[flip1995]

I'm with @lzutao here. The mem_replace_with_default lint was added in the 1.42.0 (current beta) release of Clippy for rust-1.42.0. If you're using Clippy shipped with rust 1.42.0 to check your code, we also expect that you compile your code with 1.42.0. IMO, this is a fair assumption to make.

What I can see is someone using nightly Clippy (for the newest lints and bug fixes) but then compiles with rust stable, which is a 2 version difference. But since this lint was added 2 versions after mem::take was stabilized, this reasoning doesn't apply for this lint.

I don't think, we should track for every lint, when the thing that gets linted was stabilized. That would be redundant, since this is already tracked in the rust documentation itself.

When you apply a suggestion like this, you'll get a clear warning of the rust compiler, that it is not stable in the older rust version. I don't think we need to document something, the compiler will warn you about, before opening the documentation of a lint.

And last but not least: If you're using a setup where rust versions differ by 5, you certainly actively made this decision, so you should be aware, that this could happen.