←back to thread

128 points RGBCube | 2 comments | | HN request time: 0.504s | source
1. xorvoid ◴[] No.44500308[source]
Am I the only one who thinks this is perfectly fine?

The requirements for derive Clone are clearly defined. As with much in Rust, the type signature drives things, rather than the function body (contrast with C++ generics).

Occasionally, this results in perfectly reasonable code getting rejected. Such is the case with all static languages (by definition).

But in the few cases that happen, the solutions are quite straightforward. So, I don’t feel like it’s justified to add more complication to the language to deal with a few small corner cases.

replies(1): >>44504953 #
2. bobbylarrybobby ◴[] No.44504953[source]
If you write code manually, you can forget to update it in the future. For instance, a manual implementation of PartialEq might become stale if you add new fields in the future. If you could automatically generate the implementation, and simply guide the macro to use non-default behavior (e.g. skip a field, or use a more complicated trait bound on a generic type) then you can have the advantages of generated code without the disadvantages. Seems worth trying for, IMO.