Pretty clickbaitey title.

It's possible to implement in C++... so it's not "too dangerous" for C++. It's dangerous for people who don't have knowledge of what they're doing in C++; same as in any programming language.

On the contrary, I thought it was quite apt. If you follow the article's link to this Stack Overflow answer:

https://stackoverflow.com/a/15140227/1614219

Which summarizes a discussion by the C++ standards committee to reject the C++ version of Rc, and one of the main arguments is the risk of Rc code being accidentally included in threaded code.

I would point out that this code can include: code you wrote years ago that you forgot includes Rc, code in libraries that was modified internally to use Rc and the authors forgot to mention it, code written by colleagues who aren't familiar with the pitfalls, etc. That's why this isn't a trivial problem to solve.

"Too dangerous" doesn't imply impossible.

It's too dangerous to parachute off the Eiffel tower. That doesn't mean it's impossible, periodically somebody does it.

I'm not a C++ expert but I believe it is not possible in current C++ to implement a pointer type that will cause a compiler error when it is sent to another thread.

Interesting thought experiment. While I haven’t tried it, one half-baked idea that comes to mind is disable both copy and move for the pointer and instantiate the type in C++ thread-local storage. Not that I ever would.

It is interesting! I experimented with creating a bad borrow checker for Java using annotations from

https://checkerframework.org/

It supports some level of substructural types using must-call annotations,

https://checkerframework.org/manual/#resource-leak-checker

That's almost certainly true, but first you have to define "send to another thread"