For Rust, it's the "Drop" trait that you add onto things which ultimately causes RAII behavior.
You don't need to do it as much with rust as a lot of the reasons for wanting RAII (memory management) are simply handled by the language.
For Rust, it's sort of the "Pit of success" the easy thing to do is the right thing to do. Whereas in C++, it's pretty dang easy to new something up and fail to correctly delete it.
This is true, but we shouldn't be encouraging people to reach for new/delete these days; auto Foo = std::make_unique<Foo>(args); does the right thing in a surprisngly large number of cases. It's not the only tool available, but it's a really damn good one.
I'd argue that in a language with the `new` keyword, nothing is more easy or natural than invoking it. `auto Foo = std::make_unique<Foo>(args);` is absolutely the right thing to do, but would you really be surprised to find `auto foo = new Foo(args);`?
I absolutely agree unique pointers are the right call. They just aren't necessarily the easy or natural call.
The contrast is rust where all ptrs are, by default, unique ptr and the compiler validates that for you.
It is already hard to educate people on modern language features and adoption of static analysers that enforce Core Guidelines.
Who would write the books and teaching materials for #pragma modern_defaults, and ensure it would be accepted into ISO?
Foo foo{args};
auto foo = std::make_unique<Foo>(args);
This will feel much more natural to most developers:
var foo = new Foo(args); Foo foo(args);
How's this:
The code allocates and initializes a new Foo instance with args. By using make_unique you guarantee that the destructor is called when foo goes out of scope for any reason.