(Albeit using that method to allocate in safe code is useless, since you can't use the result in any useful way. But that's what Box<T, CustomAlloc>::new will be for, once custom allocators are fully figured out.)
I believe @fps wants a "globally unsafe" mode, where all code is considered unsafe. I've wanted for a similar thing a few times, in projects where most code is in an unsafe context, and even that which isn't is typically still soundness-relevant because of ambient soundness requirements.
But even in such environments, being able to say that a specific interface is safe — to define safe abstractions even among the unsafe context — is a strong benefit, and in retrospect each of those projects would have turned out worse had they just been ambiently unsafe.
A desirable strength of Rust is that decently written non-obfuscated Rust is generally fairly locally evident as to what the code is doing and what its safety obligations are, if any, at least given the availability of type lookup. If code might be doing unsafe operations without any local indication of such (i.e. the unsafe keyword), then a good deal of this property is lost.
If you absolutely must have something like this, a source preprocessor that adds unsafe blocks everywhere would be your best bet. Nobody is likely to provide such a tool, and the use of said tool would be generally looked down on as violating a core goal of Rust.
You can define a custom #[global_allocator]. Implementing that custom global allocator will probably involve unsafe, but "all parts of the project" besides that can continue to use the safe allocation API, e.g. Box, String, and Vec will continue to present safe allocation APIs.
I'm not sure if this was ever proposed, but it would be interesting to have something like #![unsafe] or maybe #[implictly_unsafe] to mark that everything in a file implictly unsafe.. except maybe by things marked with #[safe] (or maybe even make safe a keyword)
This would still enable fine-grained annotation of safety, but with inverted polarity.
This is true, so I'm unsure if this would be a net positive. (however this is sometimes obscured by some #[attributes] being silently unsafe, among other things; the list of unsafe things in Rust is somewhat non-uniform)