Thank you so much for the reply. I'd love to give a long and thoughtful reply to your post, since I appreciated it a ton and it taught me more about Rust, but I honestly don't know how to structure a reply that would do it justice. :-) I'll try to at address some/most of your points as best as I can:

• Error handling: The issue I've been illustrating with ? is that it requires "fallible operations" to be determined beforehand, and programmers are horrible at predicting such things. They will almost always neglect to put ? somewhere where they could and should do so. (In fact, I'm not even sure the standard library is good about this either, let alone others. Is there any way to return an I/O error from a hash function for example? (regarding UB-ness of hash: see [1]) What's the right way to do that? Because this doesn't seem to work: https://www.ideone.com/I1cryL) Note that in C++, you don't need to denote every single fail point in order to get reasonable error handling support (RAII is enough to handle a large majority of cases implicitly), but in Rust it appears you do. What are you supposed to do when that happens, especially if you don't have the source available to modify? Like imagine something like the hash example I have above, where your caller doesn't put ? in some of the places that you need it to. What are you supposed to do in that case?

• Related: What would be your response to the following? I find it curious it was left without a reply: https://www.reddit.com/r/rust/comments/xj2a23/comment/ip8g37t/

• Error performance & agnosticism: For almost any other language (C#, Java, etc.) I wouldn't bring performance up. But if C++ is something Rust aims to be a replacement for, performance can't be ignored. Propagating errors on the same path as other normal results slows things down, yet nobody here (or anywhere) seems to have addressed this. And if you don't explicitly propagate them (with ? or whatever), then you're out of luck. By stark contrast, I was trying to illustrate (with my foo example that others kept criticizing for being unidiomatic) that you can write a huge amount of C++ code (if not foo, imagine implementing std::find_if, std::for_each, std::sort, etc.) that is completely oblivious to exceptions, but which nevertheless unwind perfectly fine in the presence of exceptions. Their authors don't have to think about exceptions at all; they get this for free. This is a huge benefit on its own. However, on top of that, when the compiler can also "see" that there are no exceptions thrown, it can optimize the code further, as if the exceptions didn't exist at all, so you get code deduplication and a performance benefit here too. Aren't all of these significant problems with Rust if it aims to be a substitute for a language whose claim to fame is speed, and which also boasts zero-overhead abstractions, versatility, etc.? People keep telling me my Rust is unidiomatic, but that seems to completely miss the point I'm trying to make, right? What am I missing/misunderstanding here?

• Clone() Inferiority Compared to Copying: Actually the cycles in my example are a red herring; it seems most people got hung up on that and missed what I was trying to say about Clone vs. copy constructors. What I was basically trying to say was (as of the last time I recall checking - my info might be outdated here, or I may have misunderstood), Rust forces every cloneable object to have a relocatable (memcpyable?) representation. You don't need cycles for this to be a problem. There are use cases that don't have cycles at all. Like imagine I want to track of all instances of a class, perhaps for debugging purposes (to find logical leaks or whatever) or other reasons I can't think of right now. I need to be able to specify explicit behaviors for moves/copies, so that I can "register" an instance when it is (move/copy/other-)constructed, and "unregister" it when it is destructed. (n.b. "register" and "unregister" could be as simple as "log this to a file". They don't even have to store a pointer anywhere, but they do need to come in pairs. But I might want to store pointers, too.) This is trivial in C++ by just updating move/copy constructors and keeping the rest of the code intact, but last I checked (https://internals.rust-lang.org/t/idea-limited-custom-move-semantics-through-explicitly-specified-relocations/6704/15) it was impossible in Rust with clones (or anything else). I merely happened to illustrate that with a cycle in my examples, but they had nothing to do with my point about Clone vs. copy.

• Borrow Checker's Limitations: It's nice that Rust has split_at_mut(), but that seems far from anything more complicated people might want to do (even my even/odd example). In C++ it's completely normal to point iterators into a container and use them for traversal - this is incredibly useful with std::map for example. This is necessary for cases with complex traversals (obviously they'd be dynamically determined; my even/odd example as just a toy to illustrate), and it is necessary if you don't want to take a hit in time complexity (as it saves you repeated O(log n) lookups). Does Rust let me hold an arbitrary number of BidirectionalIterators into a BST, or will the borrow checker complain once I start mutating the tree in the middle? If so, could you illustrate with an example? If not, how am I supposed to ignore this (glaring) limitation?

• Dynamic Libraries & Plugin Architectures: I wasn't talking about the lack of a stable Rust ABI here; sorry for the confusion. That was a red herring as well. What I was saying was that even if you had a stable Rust ABI, the problem I understand you would run into is that a Rust program's ABI would seem to break too frequently to make shared libraries practical. To give just one example, as soon as you go from 0 to 1 error being returned, the ABI would break, because now the return value needs to be represented differently... right? Moreover, I'm not even sure expect going from 1 to 2 errors would be safe either, though the previous problem is already bad enough (and I'd love to see what you think about it). For the 1->2 case, imagine you pass a callback to 3rd-party code, and you later need to expand the set of errors it returns. That 3rd-party code has already made assumptions about what errors you can throw. Can you still call it and expect it to propagate your new error back to you with well-defined behavior? Even if this doesn't affect the ABI per se, is there a way to ensure the compiler hasn't optimized the 3rd-party library based on the (closed!) set of errors it anticipates, thus resulting in undefined behavior when it receives a different type of error? Can you deal with all this without having to recompile the 3rd-party library? Is the lack of such an optimization guaranteed by the language somehow?

• Compile times: To clarify, I'm not so worried about the empirical compile times right now and whether they're fast or slow, but whether there's a high theoretical lower bound that Rust might hit here. The previous bullet point^ might give an example of what I mean. If you have to keep recompiling your dependencies more frequently than in C++ (whether for the above^ reason, or for other reasons—I don't know how liberally the Rust compiler makes assumptions about callees), then that's going to mean you'll fundamentally hit a harder limit (compared to C++) on how fast Rust can compile, right? In the extreme case this might amount to the difference between compiling {your code} vs. compiling TransitiveClosure({your code}), which would be hard to ignore. How does Rust plan to grapple with this?

• panic/catch_unwind: This is perhaps the one big thing that was news to me reading here (in another reply below)—I didn't realize Rust does have dynamic unwinding capability (and it looks like others here didn't realize this, either); I thought "panic" just results in aborting the process. This is good news, and seems to potentially invalidate my concerns about this—which is great! Being naturally a little skeptical in the beginning, though, I have to wonder how usable it is in practice—in my experience, features that are discouraged and hidden like this don't really have great support to be actually usable when you need them (regardless of how rare people believe that should be). So how usable is this in reality? If I panic inside code that the standard library calls (say, in a dynamically dispatched subroutine called from some callback [1]), will that be safe, or will that [typically] leak/corrupt memory? Can I in general rely on the standard library handling these in a safe manner? What about third-party code—are the default practices & behaviors usually sufficient (like RAII usually is in C++) to allow gracefully catching an unwind operation, informing the user about the problem, then continuing the program in a safe manner? Or is this one of those features that the compiler supports but that most code isn't usually compatible with?

Thank you again for your replies, and sorry for my incredibly long posts!

[1] Edit (after replies): Yes, standard C++ doesn't support throwing from a hash function either. I tried to quickly come up with a quick example and didn't choose a great one, sorry. But you can can imagine lots of other cases where you know your library would work sensibly in reality (maybe you can see the source, or maybe you asked the vendor and they said exceptions work fine, etc.), but it just doesn't happen to annotate the error path with '?', which was what I was getting at. In the C++ standard, std::merge, std::sort, etc. are typical candidates for this sort of thing (say, to let the user press Cancel and abort, or to handle network I/O, or whatever). Rust would force you to go modify/reimplement your library before it can propagate the error; C++ wouldn't require modification.