core: Add `Default::replace_default(&mut self)`

[cuviper]

No description provided.

[cuviper]

@bluss wanted something like take() for Vec. A few folks liked my bikeshed name.
ref: https://internals.rust-lang.org/t/method-take-on-vec/3371/13

[samlh]

I would prefer the bikeshed to be painted replace_with_default, as I was really confused by the title of the PR :)

[cuviper]

Hmm, replace_with_default is getting wordy, but I can see how that's clearer. Any other ideas? I will yield to popular opinion.

For an analogy, this is a bit like C++ move semantics, where the value is transferred but the origin is still left in a usable (unspecified) state. Here we're specifying the source will be default().

[alexcrichton]

Thanks for the PR! This is a stable prelude trait so despite this method being unstable it's borderline "requires an RFC" territory. (I could kinda go either way, cc @rust-lang/libs)

Also, could you elaborate on some of the rationale for this as well? Can this lead to optimizations in some cases or is it just a more ergonomic mem::replace?

[cuviper]

Yes, it's mostly just ergonomic, a generalization of Option::take. You could also optimize for classes that don't need a full memcpy, like the uninitialized portions of an ArrayVec. But that's probably already paying a full memcpy even for simple moves, so this might make little difference.

[alexcrichton]

Hm ok, if it's purely ergonomic then I'd definitely recommend an RFC :)

[cuviper]

Dang, I thought I had an easy one... :)

@bluss any thoughts? Does this meet your need?

[bluss]

Thanks for writing the PR.

I don't think it is an easy one. I don't prefer changing Default, but I can see that it has some advantages.^

The original suggestion was to add a method .take() on Vec which does the same as this method (and the same thing that Option::take does too).

The inspiration for that is threefold, the similarity with Option::take, the regular need for this call, and thirdly to make it easy to read and explain the code. It's one of those inspirations that come from discussing solutions to simple situations with newcomers to rust.

It does functionally meet the need (but the functionality was already present with replace), it is ergonomic, so that's a great plus, but with this name I don't think it is as nice as .take(), so it does not really fill my need of how I want to express myself in rust. I realize a method on a widely used trait like Default can not be named take, especially not due to the conflict with HashSet::take.

I think this is an area where we should say to be correct: it can be implemented similarly in an external crate, and we should use experience from that before including.

^ Default advantage: baseline feature generally available
^ Default drawbacks: Requires long name because it's in the default name space, Is not guaranteed to be cheap (A Take trait could possibly be specified to always be cheap to call, does not allocate a new replacement).

[cuviper]

OK, thanks for all the feedback!

To be honest, I was only mildly interested in this, enough to try for the low-hanging fruit. If someone else would like to go further with an RFC and/or external crate, please feel free!