-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ImplicitClone
for Copy
types
#32
Comments
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? |
|
Marker traits may indeed have implementation collisions:
|
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. |
Issue for implementing
ImplicitClone
for allCopy
types.As noted in yewstack/yew#3464 (comment), the entirety of all
Copy
types may receive anImplicitClone
implementation via specializations (currently nightly):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
forCopy
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.The text was updated successfully, but these errors were encountered: