| |
|
Timon Gehr
| On 7/1/24 16:00, Steven Schveighoffer wrote:
>
> D would I think need to be safe by default and use dip1000 by default to be appropriately labeled safe.
>
> I’m still trying to find out more about the criteria, because I don’t think it discusses how languages were put into these buckets of safe and unsafe.
Well, it cannot be the criteria cited in the OP:
> "Memory-unsafe languages are those that do not provide built-in memory management mechanisms, burdening the developer with this responsibility and increasing the likelihood of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython, and D."
This is plainly incorrect. D has a GC, which is a built-in memory management mechanism.
Safety is not about what you can do, but about what errors you can't make. I guess what's maybe holding D back a bit is the tendency of D programmers to opt for malloc-backed data structures with unestricted `ref` access to elements. DIP1000 can hep but is a bit restricted.
But ultimately technical concerns are probably secondary, and it is mostly about marketing (and what kind of programmers that attracts for building the ecosystem):
> With the D Programming Language, write fast, read fast, and run fast.
>
> Fast code, fast.
Compare this to:
> A language empowering everyone to build reliable and efficient software.
> Reliability: Rust’s rich type system and ownership model guarantee memory-safety and thread-safety — enabling you to eliminate many classes of bugs at compile-time.
Technically those guarantees are not fully reliable, but the main webpage says they are right in your face, that's perhaps necessary, or even sufficient.
|