RFC: Add Copy and DeepCopy trait and deriving modes

[Kimundi]

This prepares the source code for renaming clone -> copy.
Needs an snapshot to proceed.

I'm not sure if it's actually desirable at this point to make the change, but I think copy is a more fitting name than clone.

• clone might confuse people coming from, eg, java.
  • clone there is per default implemented as reference copy, and can be overriden for custom clone behavior.
  • The semantic of our Clone and DeepClone are more clear cut: Clone copies as shallow as possible, DeepClone as deep as possible.
• Our clone is also frequently just a fast, low level copy, the name clone might imply something more heavy going on per default.
• It's shorter, always good for a frequently called function.

[emberian]

This is exactly the thing that a "super-review" would be nice for. This should be discussed at a meeting before getting merged, I think.

[brson]

Please hold off on this for further discussion.

[brson]

I put it on the meeting agenda.

[Kimundi]

@cmr oh, definitively. ;)
@brson Sorry, my intention was not to just let that slip in. I realize that this is a major change.

[brson]

Consensus is to leave it as Clone, primarily to avoid the disruptive change.

[Kimundi]

Hm, sad to hear this, especially because "disruptive change" seems more like an argument for doing it as early as possible, or at least wait to the point when we have an refactoring tool that can do this fast.

Basing an decision that will affect the final language on only the annoyance of implementing it seems wrong to me...

The meeting notes argument that clone implies that more stuff is going on there than a simple memcpy I buy, though.