ImplicitClone for Copy types

[kirillsemyonkin]

Issue for implementing ImplicitClone for all Copy types.

As noted in yewstack/yew#3464 (comment), the entirety of all Copy types may receive an ImplicitClone implementation via specializations (currently nightly):

#![feature(specialization)]

default impl<T: Copy> ImplicitClone for T {
}

However, the RFC for specializations is nowhere near being done, so for this point in time ImplicitClone will still stay limited in the amount of types that will be implemented (and this issue will stay open).

Alternatively, a Rust RFC should be made that would allow ImplicitClone for Copy types: the only blocking suggestion from the Rust compiler is that the trait may have colliding implementations in future, which is not correct since the marker trait is empty, and there is nothing to collide with. The RFC would allow repeating marker trait implementations. Comment if someone makes such an RFC and I will update this issue.

[cecton]

I love this alternative idea actually. I understand specialization is complicated and requires a lot of time to stabilize but the concept of ImplicitClone is actually very simple and could already be implemented somehow.

Maybe a wild idea but why not even make an RFC to actually move ImplicitClone to the standard Rust compiler? Copy in its current state holds 2 different concepts: the memory being copied (memcpy) instead of cloning (trait Clone) + implicit copy instead of moving ownership. This could be made into two traits (Copy and ImplicitClone) so types like Rc and Arc can be moved easily into closures. It would be so much more user-friendly.

[kirillsemyonkin]

@cecton

• Name ImplicitClone feels a bit clunky for the standard library, Ic seems like something they would use lol
• If they were to do that, it would fit into type system like Copy: ImplicitClone, ImplicitClone: Clone, requiring #[derive(Clone, ImplicitClone, Copy)], and for that, the ship has already sailed long time ago (I just thought, they should auto implement Clone for Copy, instead of requiring Clone, and that could be done either with specializations or even my alternative RFC idea... actually I just looked up std::any::Any and it is impl... Any for T. I feel betrayed).
• While typing this, I already forgot what I wanted to say for this bullet point, it was something related to making it more integrated into the language itself.
• I'm just wondering for this one, but how would it integrate with .cloned(), .copied() (actually, why is not a single optimized-during-compile .cloned()?) and many other APIs that take in account the difference between the two? Our marker trait does not really have any significance like the other two.
• I know you said its a wild idea, but I still gotta note this: I doubt they are in for implicit cloning tbh. Accidental clones that would arise from this (even simple let b: Rc<...> = a;) are really not what Rust seems to be looking for, especially if people would be looking for making a C++ std 2.0 in Rust, where almost everything is implicitly cloned. Rust can't even make implicit .into() or at least upcasting number conversions (u32 -> u64).

[kirillsemyonkin]

Marker traits may indeed have implementation collisions:

• MarkerTrait is made in a library
• User of the library implements MarkerTrait for CustomType
• NonMarkerTrait that is defined in neither library nor user's code is implemented for CustomType by user
• MarkerTrait is updated to have a blanket implementation for all NonMarkerTrait types
• Now CustomType has both custom impl of NonMarkerTrait and a blanket impl of NonMarkerTrait via MarkerTrait

[cecton]

That one? https://crates.io/crates/marker_trait

[kirillsemyonkin]

That one? https://crates.io/crates/marker_trait

Not sure what's that tiny crate you linked does. A marker trait is a trait that has no required methods.