> Safety is not an absolute, it's a spectrum.
Use of the safe subset of Rust means the compiler and standard-library offer you a guarantee of the absence of undefined behaviour. That's an absolute guarantee of safety, under Rust's understanding of the word.
It doesn't give you a guaranteed absence of memory-leaks. It certainly doesn't give you a guarantee of whole-program correctness, as Rust isn't a formal verification framework. Both these properties are beyond the scope of 'safety' as Rust uses it.
> It's not disregarded.
It is. Projects are described as written in Rust, treating safe Rust and unsafe Rust equally.
> The point you are disregarding that when porting a C application to rust, unsafe rust is a step up from C, not step down from safe rust.
I explicitly acknowledged this.
> Unless you choose to rewrite from ground up (which is infeasible in many places), you'll need unsafe rust, either for binding or by using tooling that converts the C sources to rust.
Sure, no disagreement there.
> But once you have unsafe rust, you already get all the help that the borrow checker brings and you can gradually shrink the unsafe code.
Sure, and that's a good use of Rust's unsafe features.
> you seem to be advocating for absolutes
Not really. If I had meant to argue that Rust shouldn't have unsafe features, I'd have done so.
In an ideal world all code would be written in a way that completely closes the door on undefined behaviour, but we agree there are good reasons Rust includes its unsafe features, and there are good practical reasons to use them. I'm advocating for a greater emphasis on the use of the safe subset of Rust.
Written in Rust tells me something about the software. Written in 100% safe Rust tells me much more about the software. That's essentially my point.
This distinction doesn't arise with languages like C and JavaScript. All C is unsafe, and all JavaScript is safe. For languages like Rust and D, there's value in being upfront about the use of their safe subsets.