You're jumping around: exceptions being checked or not is orthogonal to returning errors from a destructor. It's true that being unchecked may make it harder to know when you need to, but the point stands that the ability to return errors from a destructor is not a way in which Rust's error handling is better than C++'s.
Additionally, the C++ solution for returning errors from destructors is also explicit in the signature.
(To be clear, I'm very firmly a fan of Rust, but I'm also a fan of accurate representations of it.)
Fine, I'll bite then(although I think my point still stands).
According to the spec current_exception() returns a smart pointer which the storage isn't specified. Part of that is implied allocation(returning bad_alloc for instance) which means you may be making a heap allocation for a pointer that could have been handled on the stack. That's going to rule out cases like the embedded space and gamedev where allocations during runtime is a big no-no.
I'm no stranger to C++ but I've been bitten so many times by exceptions. Either in libraries that didn't say they'd throw them(but then did), ABI pollution and having to get new binary drops from vendors because turning them on bloated RTTI which caused binary sizes that didn't fit. They really have no place if you plan to use the language at any sort of scale.
I think you're still looking at too much of the picture: this discussion is specifically about error handling in destructors (and how this affects finally/scope(exit)). There's numerous reasons why the checked, explicit, first-class, typed error handling of Rust is better than C++'s exceptions, but "able to use an outpointer to return an error from a destructor" isn't one of them:
1. using the outpointer is clunky and error prone
2. C++ can do the same thing (both with exceptions enabled, and with them disabled, the latter of which is pretty much the same as Rust)
(The current_exception stuff even makes it possible to handle it fairly generically in C++, so even calling arbitrary code with exceptions-on can be the normal code wrapped in catch_and_write_exception(&exceptionSlot, [&] { ... });, which works for any library code, whether it throws or not.)
> According to the spec current_exception() returns a smart pointer which the storage isn't specified
Exceptions often allocate anyway; current_exception() isn't creating a new problem.
> the latter of which is pretty much the same as Rust
If exceptions allocate that's not the same as Rust, full-stop. I'm sorry if it seems like I'm being pedantic about this point but it's a huge issue of contention for those of us who used C++ to squeeze every ounce of performance out of a platform.
Yes I can manipulate a value through pointers/refs to return a result in both, but in the Rust case I can guarantee that the value lives on the stack by passing in a reference because A: I know the full type up-front(no virtuals unless I use Box<Trait>, no std::exception* opaque types) and B: exception_ptr() makes no such claims.
> Exceptions often allocate anyway; current_exception() isn't creating a new problem.
For those of us who ship codebases with exceptions disabled by default it definitely is a problem. Unchecked exceptions make this a problem which pollutes every one of your destructors and forces you to pay the above cost.
> I'm sorry if it seems like I'm being pedantic about this point but it's a huge issue of contention for those of us who used C++ to squeeze every ounce of performance out of a platform.
You're being pedantic about something I'm not saying.
I 100% agree with what you're saying in that comment, but that isn't what this thread is about. It has now become clear that your "big gripe" with exceptions is not the inability to throw them out of destructors (which is what causes the problem with scope(exit)), but all the other problems with them.
As my previous comment said, there's lots of reasons why Rust's approach is better (I'm intimately familiar with Rust, and also work on a large C++ codebase... with exceptions disabled ;) ), but that's not what we're talking about here.
> For those of us who ship codebases with exceptions disabled by default it definitely is a problem
No, you're misreading me again: it isn't a new problem. As in, the problems with current_exception() are just the normal problems with exceptions, they aren't something specific to that function. If exceptions are okay (which they're often not; yes, I know, I get that, but that's not the point here), then using current_exception to return errors from destructors is fine.
My point is Rust and C++ both handle returning errors from destructors equally well/badly. (Your point is you, in general, prefer Rust's error handling to C++ exceptions, which is a different point.)
Additionally, the C++ solution for returning errors from destructors is also explicit in the signature.
(To be clear, I'm very firmly a fan of Rust, but I'm also a fan of accurate representations of it.)