Yes, because "safety" in English is not analogous to "unsafe" in Rust in any real manner. They are linked only in the loosest conceptual way. Rust's "safety" and "unsafe" are well defined and exact, and can be objectively determined. In the English language it is by its nature subjective.
> The usual understanding is that an unsafe function is any function that can, if passed the wrong arguments, cause Undefined Behavior.
That is, specifically AFAIK, not what it means in Rust. It's well defined there, so there's no need to resort to "the usual understanding". This causes a lot of confusion, but it doesn't need to. If someone is talking about the unsafe keyword in Rust, they're talking about Rust's definition of it and what it entails, or they're using incorrect terminology.
> Presumably, the C++ wrappers suggested here would not even be safe in that sense. They would use a lot of pointers, and cause UB if passed the wrong one.
Then there's not a lot of point in using Rust if they refuse to change that usage. It's not about using Rust to check off a box that you use some buzzword technology, it's about leveraging what it can provide that other languages can't, or can't do as well.
If someone finally decides to put a firewall in front of a server but decides its' too hard to actually limit traffic in any way so allows 0.0.0.0/0 any port, you don't congratulate them on their firewall, you tell them they just wasted everyone's time and money.
> The article argues that using unsafe correctly is impractical for Chromium because basically every Rust function would have to be marked unsafe to call into these raw C++ APIs.
To my knowledge, the way Firefox did it was to pick a system or library, provide a Rust replacement that C/C++ could call, and allow it to be moved into place. That's sane. Using rust and C++ functions on the same memory and expecting Rust to deal with C++'s pointer shenanigans may not be, in the same way I wouldn't expect mixing small amounts of Java in the JVM into a big C++ would just work unless you had hard rules about who controlled what memory/objects and made sure you never broke them.
I can't help but feel they're approach is likely to cause them more problems than needed because they're not willing to commit the sane minimal amount to make a lot of these problems not matter (replace a small self contained system). If they don't actually have any small self contained system, and they really are just passing stuff around and using some complex pointer control, and aren't willing to change that, maybe Rust isn't a good candidate to extend their project languages with.
