[klickverbot]

> D is arguably in the same bucket as Swift, and partly as Go. I don't think it's very useful to compare and contrast it against Rust.

It is easy to claim how things "arguably" are, but without providing any justification that is not a very meaningful statement to make.

D very much matches your definition of "low-level, zero-overhead (no GC) etc nature and powerful metaprogramming facilities" – the GC can be avoided easily enough. It can certainly claim to be a "better C++" in this sense. For instance, Weka.IO (a storage startup founded on D) heavily relies on D to offer exactly that, in order to implement a distributed file system with sub-100µs latency.

The fact that you can also write Python-esque code during prototyping (playing fast and loose with the GC, etc.) doesn't detract from the core identity of the language as a tool for systems programming with zero-cost abstractions.

[dgfgfdagasdfgfa]

How is D's memory safety without the GC? How does it guarantee you don't use-after-free, de-ref nulls, buffer overflow, etc?

[WalterBright]

Great question! The answer is a bit more than a simple reply can do, so:

Pointers Gone Wild: Memory Safety and D http://dconf.org/2017/talks/bright.html

[hellcatv]

It seems like use-after-free is still a potential issue, even with those guard rails. Rust deals with those through named lifetimes --would those ideas be useful in D as well?

[dgfgfdagasdfgfa]

Walter, you're always so responsive in these threads! Cheers.

[mhh__]

This is being worked on, but there is already memory safety checks implemented in the compiler (That one can use now) "-dip1000"

[int_19h]

Is the D standard library GC-free?

If not, then I would posit that it's not correct to say that it matches my definition.