I'm not missing the point of those examples. They showcase Rust vs. ridiculous C++.
See my point with making the add_one function not taking a unique_ptr. This is valid criticism and valid in more complex practical examples, too.
See my point with making the add_one function not taking a unique_ptr. This is valid criticism and valid in more complex practical examples, too.
BigInteger& add_one(BigInteger& num)
void add_one(std::unique_ptr<BigInteger> num)
The though-process goes like this:
* Do you need read-only access to the argument, take a const T&
* Do you need to modify the argument, take a T (by value), letting the call site decide to either pass an rvalue (move it, no copy), or an lvalue (copy)
There simply is no need for unique_ptr<BigInteger>, as BigInteger already handles its resources internally (with move semantics). It's the same reason as to why an owning pointer to a vector is silly when a vector already handles ownership of its resources.
http://klmr.me/slides/modern-cpp/#9 is exactly about this.
I can see where you're coming from in pushing for all-value semantics, taking advantage of the mechanisms built into the language to control how those semantics play out.
I think it's worth remembering through all of this that getting just the right semantics requires a little more effort and thought on the part of the callee, in C++-land, as well as which the relative lack of consistency (and opaqueness) in these semantics, at least in the absence of a full IDE or similar to jump to signatures.
Oh and briefly, the C++ may be unidiomatic, but it's perhaps useful as a C++ mimicry of the Rust code to show maximally similar semantics?
I think perhaps the dismissive nature of your GP post blinded me to exactly what standard you wanted the C++ to hold to (oh and also, swapping out heap allocation still seems to be missing the point, as there are definitely cases where that's the 'right' behaviour)