Make cloned values indistinguishable

[Stebalien]

Define "Returns a copy of the value" to mean a == b -> a == b.clone().

---

Original unworkable proposal (see discussion below):

Currently, clone explicitly doesn't guarantee that the following are always indistinguishable:

let a = f();
let b = g();
let c = b.clone();
h(a, b);

let a = f();
let b = g();
let c = b.clone();
h(a, c);

This is unfortunate. However, the trait does say that Clone::clone() "Returns a copy of the value." which could imply indistinguishably (i.e., a copy of a value is indistinguishable from the original). It would be nice to make this explicit (so that, e.g., a == b implies a == b.clone()).

/cc #1203

[arielb1]

That's because it does not. For example, it is totally fine to put an interior address into some data structure.

[Stebalien]

That's because it does not. For example, it is totally fine to put an interior address into some data structure.

Yes but it shouldn't be exposed. That's why I said indistinguishable, not identical. That is, if I flip a fair coin and give you either a or a.clone(), you shouldn't be able to guess which one I gave you (ignoring timing, power, unsafe, etc.).

[durka]

cc #1521

[oli-obk]

in case of Rc, equality stands, because it is forwarded to the inner type, but cloning is exposed, because try_unwrap will fail after a clone.

So you can only guarantee that it's not exposed which one is the original and which one is the clone, but only if you always clone before you try to figure out if a value is a clone.

[Stebalien]

@oli-obk that's why I did it that way in the example (I wasn't thinking about Rc but Clone side effects in general). However, I somehow didn't notice that this would make this restriction useless in solving the linked issue. Regardless, I still think a restriction like this would be useful.

[oli-obk]

It's very hard to enforce this rule. You'd need to ensure that clone doesn't modify any fields that are accessible outside the module. I'll evaluate if it's possible to write a lint for that.

[ticki]

@oli-obk, I don't think @Stebalien propose to enforce it, but rather add a "rule", like the hash rule:

If you are also implementing Eq, there is an additional property that is important:

k1 == k2 -> hash(k1) == hash(k2)

In other words, if two keys are equal, their hashes should also be equal. HashMap and HashSet both rely on this behavior.

So just state that this is the expected behavior of clone.

[Stebalien]

@oli-obk exactly what @ticki said. Basically, precisely define that "returns a copy" means that, after cloning, the clone and the original are indistinguishable (for some reasonable definition of indistinguishable that doesn't involve the physical world).

[ticki]

I think a rule like:

a == b → a == b.clone()

[durka]

@ticki in other words, tying Clone to PartialEq?

[Stebalien]

@ticki that would also be nice but is slightly different and neither implies nor is implied by my rule. However, it would solve my problem with #1203 because a == b.clone() → hash(a) == hash(b.clone()) which means that hash(b) == hash(b.clone()).

[durka]

@Stebalien what is your rule? The "reasonable definition of indistinguishable" needs to be decided.

[Stebalien]

@durka My original thinking was "indistinguishable using the provided API". That is, you can't time things, read raw memory, use unsafe shenanigans, etc. However, you'd also have to ban looking at locations of objects in memory (casting pointers to ints) so I'm no longer sure this proposal is workable.

[ticki]

They aren't indistiguishable in the current API. See Rc for example.