I actually don't think so. I've seen plenty of Rust libraries that copy strings about 5 times unnecesssarily between usages, just because `.clone()`, substrings and co are so convenient. Those all could have been optimized away, but the authors of that code didn't knew or didn't try.

And if you do `MyAwesomeStructure::new()` you might actually trigger a whole bunch of allocations which are invisible.

So a "yes" from my side on Rusts ability to remove allocations if you try hard enough. A "no" however on allocations being extremely explicit and easy to see for non experts.

dthul's comment [0] covers my point of view fairly well. Clones and new are easy to spot, you might not be careful about them because you do not care or have other priority but you can find/grep them quickly: they are explicit.

Meanwhile C++ has a lot of implicit memory allocation and things that might or might not allocate.

[0]: https://news.ycombinator.com/item?id=24061235

Unless you are going to review the whole code, written from scratch, there is no way to actually be aware of all allocations in Rust without help from a memory profiler.

Just one or two days ago I asked here on HN how memory allocations in C++ are considered to be more hidden than in Rust and got some good replies: Especially constructors, copy constructors, assignment operators etc. can introduce non-obvious allocations.

For example:

  T t;
  a = b;
  T t2 = t;

can all allocate in C++. The equivalent in Rust:

  let t: T; // won't allocate
  let t = T::new(); // might allocate
  a = b; // won't allocate
  let t2 = t; // won't allocate
  let t2 = t.clone(); // might allocate

So in Rust you can tell that as long as there is no function call, there won't be an allocation.

Like operator overloading and implicit conversations.

True, those are even more places where C++ can implicitly allocate. The operator overloading also applies to Rust. Rust has no implicit conversions though, which are arguably worse since they are invisible (that's why I usually mark all my expensive single argument constructors as "explicit").

Sure it has, you cannot ensure Deref implementations don't allocate.

While technically true, the documentation makes it very clear that Deref should only be implemented for smart pointers and never fail. So no allocations in practice.

Ah problem solved then, we just need to document very clear that C code should not corrupt memory, how did I never thought of it.

I think the point was more that allocations are fairly explicit.

There are a few places in C++ where allocation can happen pretty much invisibly. A copy constructor is an example of that. You might see a new allocation simply by calling a method.

With rust, you usually won't see an allocation unless it is explicitly called for. You can follow the call tree and very easily pick out when those allocations are happening.

Rust also has operator overloading and implicit conversations, both can cause memory allocations.

Certainly. However, both of those things (from what I've seen) are fairly rare.

The C++ copy constructor comes up fairly frequently.

Like unsafe Rust code, there is the theory and then there are the code bases that one finds out in the wild on crates.io and in-house, not necessarily using best practices.

Rust does not have implicit type conversions.

Via Deref.

Not in practice. It's only used for reference coercions to existing objects.

You would need to ignore the documentation and bend over backwards to use it for an actual type conversion, because you can only return references.

Bending backwards is a synonym to code quality delivered by consulting/offshoring projects across most big corporations.