# [derive(Clone)] Is Broken

by RGBCube • 1 year ago

128 123 1 year ago

we cannot just require all generic parameters to be Clone, as we cannot assume they are used in such a way that requires them to be cloned.

I don't understand what "used in such a way requires them to be cloned" means. Why would you require that?

rocqua• 1 year ago

A type might have a generic parameter T, but e.g. use it as a phantom marker.

Then even if T isn't cloneable, the type might still admit a perfectly fine implementation of clone.

xvedejas• 1 year ago

Right now the derive macro requires `T` be `Clone`, but what we actually want to require is only that each field is clone, including those that are generic over `T`. eg `Arc<T>` is `Clone` even though `T` isn't, so the correct restriction would be to require `Arc<T>: Clone` instead of the status quo which requires `T: Clone`

nithssh• 1 year ago

This is the best explanation I've read of this limitation

Xunjin• 1 year ago

Thank you, summarized perfectly.

tinco• 1 year ago

That's the crux of the article. There's no good reason for this requirement, at least none that arise in the article, so the author concludes it must be a mistake.

I think it's a bit cynical that it would cost at least 4 years for this change to be admitted into the compiler. If the author is right and there is really no good reason for this rule, and I agree with the author in seeing no good reason, then it seems like something that could be changed quite quickly. The change would allow more code to compile, so nothing would break.

The only reason I could come up with for this rule is that for some other reason allowing non complying type parameters somehow makes the code generation really complex and they therefore postponed the feature.

the_mitsuhiko2• 1 year ago

The only reason I could come up with for this rule is that for some other reason allowing non complying type parameters somehow makes the code generation really complex and they therefore postponed the feature.

The history of this decision can be found in details in this blog post: https://smallcultfollowing.com/babysteps//blog/2022/04/12/im...

The key part:

This idea [of relaxing the bounds] is quite old, but there were a few problems that have blocked us from doing it. First, it requires changing all trait matching to permit cycles (currently, cycles are only permitted for auto traits like Send). This is because checking whether List<T> is Send would not require checking whether Option<Rc<List<T>>> is Send. If you work that through, you’ll find that a cycle arises. I’m not going to talk much about this in this post, but it is not a trivial thing to do: if we are not careful, it would make Rust quite unsound indeed. For now, though, let’s just assume we can do it soundly.
The other problem is that it introduces a new semver hazard: just as Rust currently commits you to being Send so long as you don’t have any non-Send types, derive would now commit List<T> to being cloneable even when T: Clone does not hold.
For example, perhaps we decide that storing a Rc<T> for each list wasn’t really necessary. Therefore, we might refactor List<T> to store T directly […] We might expect that, since we are only changing the type of a private field, this change could not cause any clients of the library to stop compiling. With perfect derive, we would be wrong.2 This change means that we now own a T directly, and so List<T>: Clone is only true if T: Clone.

moomin• 1 year ago

Haskell does this. If you derive Eq, it puts a condition on the generic parameter(s) requiring them to be Eq as well. Then if you use it with something that doesn’t implement Eq, your generic type doesn’t either.

It helps if you can express these preconditions in the first place, though.

hardwaresofton2• 1 year ago

Haskell has, like-for-like, a better type system than Rust.

That said, Rust is just enough Haskell to be all the Haskell any systems programmer ever needed, always in strict mode, with great platform support, a stellar toolkit, great governance, a thriving ecosystem and hype.

Lots of overlap in communities (more Haskell -> Rust than the other way IMO) and it's not a surprise :)

01HNNWZ0MV43FF• 1 year ago

I have respect for Haskell because I saw it long before I saw Rust, and I love the ideas, but I never got around to actually using Haskell.

I think an IO monad and linear types [1] would do a lot for me in a Rust-like

[1] Affine types? Linear types? The ones where the compiler does not insert a destructor but requires you to consume every non-POD value. As someone with no understanding of language theory, I think this would simplify error handling and the async Drop problem

evertedsphere• 1 year ago

that's incorrect

haskell implements the "perfect derive" behaviour that the blog post is complaining about rust's lack of. the constraint is only propagated to the field types when using a haskell derive, not the parameters themselves (as in rust)

so the following compiles just fine:

    data Foo -- not Eq

    data Bar a = Bar 
      deriving Eq

    f :: Eq (Bar Foo) => ()
    f = ()

lidavidm• 1 year ago

Someone on the issue they made explained why Clone is "broken": https://github.com/JelteF/derive_more/issues/490#issuecommen...

Which links to this blog post explaining the choice in more detail: https://smallcultfollowing.com/babysteps/blog/2022/04/12/imp...

sbt567• 1 year ago

from Niko's post:

In the past, we were blocked for technical reasons from expanding implied bounds and supporting perfect derive, but I believe we have resolved those issues. So now we have to think a bit about semver and decide how much explicit we want to be.

samsartor• 1 year ago

I have a crate with a "perfect" derive macro that generates where clauses from the fields instead of putting them on the generic parameters. It is nice when it works, but yah cyclical trait matching is still a real problem. I wound up needing an attribute to manually override the bounds whenever they blow up: https://docs.rs/inpt/latest/inpt/#bounds

mmastrac• 1 year ago

I did a similar thing for derive-io. It greatly improved the ergonomics of the macro.

https://docs.rs/derive-io/latest/derive_io/

Being able to handle directly recursive type bounds would be an awesome improvement to the compiler, IMO.

loa_in_• 1 year ago

Automatically deriving Clone is a convenience. You can and should write your own implementation for Clone whenever you need it and automatically derived implementation is insufficient.

josephg13• 1 year ago

But this issue makes it confusing & surprising when an automatically derived clone is sufficient and when its not. Its a silly extra rule that you have to memorise.

By the way, this issue also affects all of the other derivable traits in std - including PartialEq, Debug and others. Manually deriving all this stuff - especially Debug - is needless pain. Especially as your structs change and you need to (or forget to) maintain all this stuff.

Elegant software is measured in the number of lines of code you didn't need to write.

0rzech3• 1 year ago

It's surprising up to the moment the compilation error tells you that all of the members have to implement derived trait.

Nevertheless, it would be cool to be able to add #[noderive(Trait)] or something to a field not to be included in automatic trait implementation. Especially that sometimes foreign types do not implement some traits and one has to implement lots of boilerplate just to ignore fields of those types.

I know of Derivative crate [1], but it's yet another dependency in an increasingly NPM-like dependency tree of a modern Rust project.

All in all, I resort to manual trait implementations when needed, just as GP.

[1] https://crates.io/crates/derivative

atoav• 1 year ago

The same is true for memory allocation. But I do not think it makes sense that everybody has to write memory allocators from scratch because a few special cases require it.

j-pb3• 1 year ago

I disagree; Elegant software is explicit. Tbh I wouldn't mind if we got rid of derives tomorrow. Given the ability of LLMs to generate and maintain all that boilerplate for you, I don't see a reason for having "barely enough smarts" heuristic solutions to this.

I rather have a simple and explicit language with a bit more typing, than a perl that tries to include 10.000 convenience hacks.

(Something like Uiua is ok too, but their tacitness comes from simplicity not convenience.)

Debug is a great example for this. Is derived debug convenient? Sure. Does it produce good error messages? No. How could it? Only you know what fields are important and how they should be presented. (maybe convert the binary fields to hex, or display the bitset as a bit matrix)

We're leaving so much elegance and beauty in software engineering on the table, just because we're lazy.

jhugo6• 1 year ago

Elegant software is measured in the number of lines of code you didn't need to write.

Strong disagree. Elegant software is easy to understand when read, without extraneous design elements, but can easily have greater or fewer lines of code than an inelegant solution.

eqvinox• 1 year ago

The entirety of any programming language is a convenience. You could just write your code in assembly; I don't think your argument is "automatic". Question is, how much does this particular convenience matter?

The fact that people are writing blog posts and opening bugs about it (and others in the comments here recount running into the issue) seems to indicate this particular convenience matters.

benreesman5• 1 year ago

Haskell/GHC gets this right without any hand-wringing and about 3-4x the practical historical burden and without relying on the runtime.

The Rust community is very adamant as a general thing that "you're holding it wrong" when people complain about e.g. BDSM passing semantics, but it's also got REIR/RIIR, which is kinda like "you're holding it wrong" for programming.

These two things together are a category error.

fn-mote• 1 year ago

By RIIR you mean “Rewrite it in Rust”? I looked it up because I was hoping to get something more substantive from the post, but that’s all I could find.

qwertox• 1 year ago

LLMs are broken, too:

"Of course. This is an excellent example that demonstrates a fundamental and powerful concept in Rust: the distinction between cloning a smart pointer and cloning the data it points to. [...]"

Then I post the compiler's output:

"Ah, an excellent follow-up! You are absolutely right to post the compiler error. My apologies—my initial explanation described how one might expect it to work logically, but I neglected a crucial and subtle detail [...]"

Aren't you also getting very tired of this behavior?

renewiltord• 1 year ago

Haha, I encountered the opposite of this when I did a destructive thing recently but first asked Gemini, then countered it saying it’s wrong and it insisted it was right. So the reality they encountered is probably that: it either is stubbornly wrong or overly obsequious with no ability to switch.

My friend was a big fan of Gemini 2.5 Pro and I kept telling him it was garbage except for OCR and he nearly followed what it recommended. Haha, he’s never touching it again. Every other LLM changed its tune on pushback.

ramon156• 1 year ago

You should check Twitter nowadays, people love this kind of response. Some even use it as an argument

darkwater2• 1 year ago

And this is why basically LLMs are "bad". They have already reached critical mass adoption, they are right or mostly right most of the time but they also screw up badly many times as well. And people will just not know, trust blindly and going even deeper down in the spiral of the total absence of critical judgement. And yeah, it also happened with Google and search engines back in the day ("I found it on the web so it must be true") but now with LLMs it is literally tailored to what you are asking, for every possible question you can ask (well, minus the censored ones).

I keep thinking the LLM contribution to humanity is/will be a net negative in the long run.

the_mitsuhiko2• 1 year ago

Aren't you also getting very tired of this behavior?

The part that annoys me definitely is how confident they all sound. However the way I'm using them is with tool usage loops and so it usually runs into part 2 immediately and course corrects.

bt1a2• 1 year ago

Well, they're usually told that they're some unicorn master of * languages, frameworks, skillsets, etc., so can you really fault them? :)

rfoo• 1 year ago

TBH I'm tired of only the "Ah, an excellent follow-up! You are absolutely right <...> My apologies" part.

IshKebab• 1 year ago

Yeah they definitely didn't do that in the past. We've lost "as a large language model" and "it's important to remember" but gained "you're absolutely right!"

I would have thought they'd add "don't apologise!!!!" or something like that to the system prompt like they do to avoid excessive lists.

codedokode2• 1 year ago

Languages like Rust and C seem to be too complicated for them. I also asked different LLMs to write a C macro or function that creates a struct and a function to print it (so that I don't have to duplicate a field list) and it generates plausible garbage.

bigfishrunning2• 1 year ago

LLMs only ever produce plausible garbage -- sometimes that garbage happens to be right, but that's down to luck.

tucnak5• 1 year ago

A bit off-topic, but every time I read some sophisticated Rust code involving macros, I cannot help but think that something went wrong at some point. The sheer complexity far outpaces that of C++, and even though I'm sure they would call C++ on undefined behaviour (and rightfully so) it seems less of it has to do with memory and thread-safety, and moreso with good old "C++ style" bloat: pleasing all, whilst pleasing none. Rust doesn't seem worthwhile to learn, as in a few years time C++ will get memory safety proper, and I could just use that.

Maybe this is an improvement on templates and precompiler macros, but not really.

junon4• 1 year ago

None of this has to do with the complexity of macros.

And no, sorry, the complexity of C++ templates far outweighs anything in Rust's macros. Templates are a turing complete extension of the type system. They are not macros or anything like it.

Rust macro rules are token-to-token transformers. Nothing more. They're also sanitary, meaning they MUST form valid syntax and don't change the semantics in weird ways like C macros can.

Proc-macros are self-standing crates with a special library type in the crate manifest indicating as such, and while they're not "sanitary" like macros rules, they're still just token to token transformers that happen to run Rust code.

Both are useful, both have their place, and only proc macros have a slight developer experience annoyance with having to expand to find syntax errors (usually not a problem though).

codedokode2• 1 year ago

Proc macros are implemented in an unsafe way because they run arbitrary code during compilation and access any files. I do not like it.

Also I think it would be better if they operated with reflection-like structures like functions, classes, method rather than tokens - they would be easier to write and read.

coldtea• 1 year ago

The sheer complexity far outpaces that of C++

Not even close. Rust Macros vs C++ templates is more like "Checkers" vs "3D-chess while blindfolded".

Rust doesn't seem worthwhile to learn, as in a few years time C++ will get memory safety proper

C++ getting "memory safety proper" is just adding to the problem that's C++.

It being a pile of concepts, and features, and incompatible ideas and apis.

selfmodruntime• 1 year ago

I write both for a decade now and I disagree immensely. If Dante knew of the horrors of CPP template compiler errors he would've added an eighth ring.

bigfishrunning2• 1 year ago

I'm convinced that the only reason anyone's still using C++ is that they refuse to learn any other language, and the features they want may get added eventually. C++ is an absolute mess.

tucnak5• 1 year ago

Rust is clearly aiming to match C++ in complexity.

I don't know whether this is “Death by committee” in a new wrapper, only this time it's the "community," driven by Github emojis, as opposed to legacy processes you would find in C++ committees. Upon closer inspection, there's so much more in common between the two than it would seem! The most glaring difference is cadence. C++ is evolving slowly, and the newer stuff is not rushed into codebases. Rust projects are commonly staying on the very latest stable releases, & in some instances, nightly builds—to compile. I primarily interact with Rust codebases in the context of Postgres extensions, and I can tell you one thing: constantly having to update Rust toolchain to keep my databases up to date is a _massive_ chore.

Curiously, it would appear that the niche Rust is occupying nowadays has very little overlap with C++ applications, and so much more overlap with C. We're beginning to see more and more of Rust creeping into C projects. Meanwhile, the not-so-recent addition of smart pointers, coroutines, and the more recent improvements on these designs have allowed C++ codebases to evolve at predictable, clearly-defined pace. There's definitely a battle for C++ mindshare going on, and it's really not been good outcomes for Rust people. I'd like to remind you that most large-scale orgs where performance and stability truly matters, are still overwhelmingly C++. The HPC world basically runs on C++. The AI landscape, that is, you could make an argument, merely the extension of HPC—is similarly dominated by C++. CUDA is fundamentally an extension of C++. The larger CUDA toolkit and programming guides primarily use C++ syntax and features. Legacy? Sure. This is also the case for the majority of emergent projects in the field, including ROCm, JAX, Tenstorrent stack, and consequently the vast majority of higher-order frameworks such as llama.cpp, torch, vLLM, TensorRT—all rely on C++ compilers. Rust is virtually non-existent here, which was surprising to me originally, as I would expect Rust people to be interested in homogeneous computing, but it's started making sense when I looked at Rust-CUDA compatibility matrix.[1] Turns out, it doesn't really support anything useful for performance, and the things that it does support—all have asterisks next to them.

The Rust community is obsessed with a handful hyper-important projects, such as Linux kernel, Android, Postgres (via pgrx[2], where it has been incredibly useful!) etc. IMHO, this is very telling, & a part of the larger strategy. Ignore, or re-write small projects with no intent to maintain them later, abandon the more ambitious Rust-native projects, and focus on some of the most high-profile C projects with sufficiently-large surface area, where memory safety has traditionally been a problem. You could make an argument that Linus Torvalds is, frankly, exploiting Rust evangelists, and avoiding any bad publicity that denying them completely would entail, instead opting to direct their energies towards the most boring stuff possible: the driver subsystems. This is changing, of course, most notably with bcachefs (Kent is very fond of Rust!) and we have recently seen how that played out.

The Rust Foundation needs to think about optics; it doesn't look good at all.

On the other hand, I've grown to appreciate, and indeed, tempted to write some simple programs for Xous[3], of Precursor fame, which is a really nice bit of kit, and cleverly designed, too. (See pddb[4] work by bunnie circa 2022, it's really quite exciting!) Honestly, this is Rust at its best: a Rust project written from scratch, for good, technical, no-bullshit, no-compromise reasons where it matters the most, and actively maintained, too. Although with the return of memory tagging technology (pioneered by IBM in the 90's) in Arm v9, formally-validated CHERI designs, I'm not yet convinced Rust itself provides enough oomph, hype notwithstanding, to justify much wider adoption. It's been 10 years since Rust 1.0 and the wider industry adoption is otherwise quite underwhelming. They're no longer the new kid on the block; in view of "speedrunning" feature cadence, most notably culminating in the whole async debacle—it's not looking good at all. The Rust Foundation is routinely exploited by big corps in the stark-naked pursuit to harvest young talent, but other than a few small, hyper-useful applications, like ripgrep, alacritty, a few Rust-only shops (Oxide?) and activism largely directed towards legacy C projects, recognised by StackOverflow as "the most loved language" who knows how many years in a row, industry-wide adoption really has been lackluster _at best_.

Contrary to popular belief, C++ is getting easier on the eyes as years go by, at the same time Rust is only getting harder to read. I really liked the direction they originally took back in 2014, but they're now far beyond the point of no return; the proc-macros and arcane cargo mechanics, are only making the matter worse. If I were a betting man, I would predict that C++ will eventually incorporate most of what makes Rust great: borrow-checker, and many alternative approaches are floating, & gaining traction. The static analysis and perf-class tools have come a long way. Fuzzing, too. Modern C++ is already very different from C++ of 10 years ago, and many orgs choose to only use a specific subset of it. The same is happening in async Rust, but the larger language and tooling design doesn't lend to "siloing" as well. I personally stopped writing C++ professionally for 5 years after I stopped contributing to KDE projects, and when I came back to learn about lambdas, smart pointers, move semantics and all, it was quite straightforward. The amount of tooling that C++ had accumulated during this time is quite staggering, and their traction speaks for itself.

In 2025, more C++ is being written than at any time in the past, and young people are learning it, too. To them, from POV of "Modern C++" a lot of arguments Rust people are making—seemingly falls on deaf ears. If C++ were the dominant ideology, and Rust the subverting one, it's clear that the former is set on incorporating the latter in its discourse. What usually happens in such scenarios is longterm it boils down to taste. IMHO, in matters of taste, C++ is more flexible (to agreed-upon subsets) than Rust could ever allow today, and I struggle to see how this asymmetry could be reconciled; there is seemingly no appetite for it in Rust circles outside of async runtimes.

EDIT: Don't forget about LLM technology! There's orders of magnitude of C and C++ code of various styles around. The primary selling-point of Rust is that it enables memory and thread-safety, right? If the sufficiently-advanced AI agent runtime is able to troubleshoot and address them in time, it would become much less of an issue. Many security companies are already using LLM tooling to catch various vulnerabilities, and sometimes even bother the maintainers with it, demanding CVE's assigned and all. There was a thread on HN recently covering this topic. The agent runtimes have dabbled in super-optimisation and even writing highly-sophisticated fused kernels; guess what language it's all been done with?

[1] https://github.com/Rust-GPU/Rust-CUDA/blob/main/guide/src/fe...

[2] https://github.com/pgcentralfoundation/pgrx

[3] https://github.com/betrusted-io/xous-core

[4] https://www.bunniestudios.com/blog/2022/the-plausibly-deniab...

csomar• 1 year ago

Derive Clone is not broken. It is basic. I’d say this is a good area for a dependency but not the core Rust functionality. Keep derive simple and stupid, so people can learn they can derive stuff themselves. It also avoids any surprises.

josephg13• 1 year ago

I disagree. I think the current behaviour is surprising. The first time I ran into this problem, I spent half an hour trying to figure out what was wrong with my code - before eventually realising its a known problem in the language. What a waste of time.

The language & compiler should be unsurprising. If you have language feature A, and language feature B, if you combine them you should get A+B in the most obvious way. There shouldn't be weird extra constraints & gotchas that you trip over.

MangoToupe2• 1 year ago

I don't see it as a problem, personally. It's consistent behavior that I don't find surprising at all, perhaps because I internalized it so long ago. I can understand your frustration tho

in the most obvious way.

What people find obvious is often hard to predict.

mrbook22• 1 year ago

skill issue. Arc should allow Clone, even if the underlying is not `impl Clone`.

Ar-Curunir• 1 year ago

The solution is to use a derive macro like derivative or educe.

DougBTX• 1 year ago

Agreed, a screwdriver isn’t broken just because it isn’t a good hammer. The title seems misleading, I was expecting a bug, memory unsafe etc.

Allowing more safe uses seems OK to me, but obviously expanding the functionality adds complexity, so there’s a trade off.

atemerev• 1 year ago

I mean, how this is not core Rust functionality if you need clone for many things unless you want to fight the borrow checker for yet another day?

bloppe2• 1 year ago

I don't see how "the hard way" is a breaking change. Anybody got an example of something that works now but wouldn't work after relaxing that constraint?

yuriks• 1 year ago

It relaxes the contract required for an existing type with derive(Clone) to implement Clone, which might allow types in existing code to be cloned where they couldn't before. This might matter if precluding those clones is important for the code, e.g. if there are safety invariants being maintained by Type<T> only being clonable if T is clone.

bloppe2• 1 year ago

Ok let's say there's existing code that requires that a type is not Clone. Then that type definitely would not have #[derive(Clone)] applied to it. So it would not be affected by the change. So it would not be broken.

It's only a breaking change if code that previously worked stops working without changing the code.

exfalso• 1 year ago

Eh. It's a stretch to call it "broken"

jhugo6• 1 year ago

we cannot just require all generic parameters to be Clone, as we cannot assume they are used in such a way that requires them to be cloned.

No, this is backwards. We have to require all generic parameters are Clone, as we cannot assume that any are not used in a way that requires them to be Clone.

The reason this is the way it is is probably because Rust's type system wasn't powerful enough for this to be implemented back in the pre-1.0 days. Or it was just a simple oversight that got stabilized.

The type system can't know whether you call `T::clone()` in a method somewhere.

berkes• 1 year ago

The type system can't know whether you call `T::clone()` in a method somewhere.

Why not?

jhugo6• 1 year ago

Types don't carry behavioral information about what the method does internally. Everything about a method is known from its signature.

The compiler doesn't introspect the code inside the method and add additional hidden information to its signature (and it would be difficult to reason about a compiler that did).

enricozb2• 1 year ago

For structs, why couldn't rust check the necessary bounds on `T` for each field to be cloned? E.g. in

    #[derive(Clone)]
    struct Weird<T> {
      ptr: Arc<T>,
      tup: (T, usize)
    }

for `ptr`, `Arc<T>: Clone` exists with no bound on `T`. But for `tup`, `(T, usize): Clone` requires `T: Clone`.

Same thing for other derives, such as `Default`.

jhugo6• 1 year ago

Because it doesn't know if you're relying on T being Clone in method bodies. The internal behavior of methods is not encoded in the type system.

chrismorgan4• 1 year ago

The type system can't know whether you call `T::clone()` in a method somewhere.

It’s not about that, it’s about type system power as the article said. In former days there was no way to express the constraint; but these days you can <https://play.rust-lang.org/?gist=d1947d81a126df84f3c91fb29b5...>:

  impl<T> Clone for WrapArc<T>
  where
      Arc<T>: Clone,
  {
      …
  }

jhugo6• 1 year ago

Yeah. My bad. I got annoyed by the "is broken" terminology of TFA and wasn't thinking clearly :/

almostdeadguy• 1 year ago

All the #[derive(Clone)] does is generate a trait impl of Clone for the struct, which itself can be bounded by trait constraints. It doesn't have to know that every use of the struct ensures generic parameters have to/don't have to be Clone. It doesn't have to make guarantees about how the struct is used at all.

It only needs to provide constraints that must hold for it to call clone() on each field of the struct (i.e. the constraints that must hold for the generated implementation of the fn clone(&self) method to be valid, which might not hold for all T, in which case a Struct<T> will not implement Clone). The issue this post discusses exists because there are structs like Arc<T> that are cloneable despite T not being Clone itself [1]. In a case like that it may not be desirable to put a T: Clone constraint on the trait impl, because that unnecessarily limits T where Struct<T>: Clone.

[1] https://doc.rust-lang.org/std/sync/struct.Arc.html#impl-Clon...

m3talsmith• 1 year ago

Just looking at the examples, you can tell that they wouldn't compile: the other structs passed in don't derive the trait as well, nor implement it. It's really simple, not broken.

kzrdude• 1 year ago

The only thing that needs change with derive(Clone) is to add an option to it so that you easily can customize the bounds. Explicitly.

Surac• 1 year ago

it seems i have a personal dislike for rust syntax. i think non of the code should compile because they are just ugly :)

xupybd• 1 year ago

Amazing site from someone so young

xorvoid• 1 year ago

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.

bobbylarrybobby• 1 year ago

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.

PontingClarke• 1 year ago

Great write-up! It’s a solid reminder that #[derive(Clone)] can introduce subtle behavior in deeply nested or generic types. Automation is helpful—but shouldn't replace carefully reviewing your code's intent. Thanks for bringing attention to this!

# [derive(Clone)] Is Broken

Related Stories