D not considered memory safe

[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.