> What your obviously remark misses out is my second sentence "Outside HN, CppCon and C++Now bubbles not all C++ codebases are as clean as we would wish them to be.".

Right, but we're not discussing C++ are we? We're discussing RAII. C++'s mistakes are C++'s mistakes, adding RAII to a language doesn't imply you have to replicate C++'s mistakes, nor are C++'s mistakes issues with the concept of RAII, or destructors.

Had RAAI been properly implemented in C++, doing something like new std::string("something") should have been a compiler error.

From type theory point of view, ideally RAII aware types should only compose with outher RAII types without escape hatches.

Rust and Ada do it better in this regard.

What do you imagine is typologically wrong with new std::string("pjmlp")?

Yes, new is itself too low-level, so std::make_unique("pjmlp"s) is the modern idiom; and std::string is limited (expect unicode-aware strings in '23). But a heap-allocated string object is a thing equally easy and useful to express in Rust. (Dunno about Ada: does it have any analog of destructors, yet?)

> What do you imagine is typologically wrong with new std::string("pjmlp")?

You have to remember to `free` the string explicitely.

> Yes, new is itself too low-level, so std::make_unique("pjmlp"s) is the modern idiom

Is it? Isn't that going to create an `unique_ptr<char*>`?

Nope: https://en.cppreference.com/w/cpp/string/basic_string/operat...

> You have to remember to `free` the string explicitly

That is not a type problem. It is far from clear what pjmlp means here. unique_ptr should have been invented in 1985? Time machines have their own problems.