This isn't a zero-sum game! D is a fine language.

[1]: https://dlang.org/spec/function.html#interpretation

Actually you can do this on CTFE on D, doing an import of a file and dumping it to an enum. The only big pitfall of this, is that enforces to read the whole file by the compiler.

It can be done with:

    void[] ctData = import("file.xml");

An important difference is that the compiler doesn't know it's using that file ahead of time, which could have some unforeseen consequences, but I don't see anything immediately worrying about that fact since the compiler didn't know about the source either at it's own compile time.

Considering what we've known about the typical behavior of production programs for decades, why isn't there also an "Initialization Time" in addition to Compile Time and "runtime." (Steady State Time?)

I think it has a bad rap because it's often used to initialize some kind of global state, with all the cons global state brings.

So then what if the language didn't have global state, or only had immutable global state?

  > Compile time IO doesn't make much sense either.

As it turns out (IME) referencing arbitrary data (such as a database schema queried from a 'live' database) is actually of quite limited value.

Where I actually agree that it makes sense is the 'read-a-checked-in-file-and-generate-code-at-compile-time-from-that'. Otherwise, you're mostly just looking at a lot of pain compared to just generating code (that you might check in).

It's very nice, but it isn't memory safe.

Probably the biggest memory safety issue is buffer overflows, and D does a good job stopping that (array overflow checking).

Context: safe Rust is also a subset of unsafe Rust. But when people mention a language without qualifiers, they mean whatever the default is. D (appears) to default to a non-memory safe language, and Rust defaults to a memory-safe one. I believe this is what OP meant. (this also ignores the relative feature sets of the various sub/super-sets)

However, I don't think it is such a big deal, since you can patch it quite well. Mark your main function as @safe and you are force to make everything @safe (or @trusted as a workaround). The type checker will tell you where to look next.

It is interesting that Rust functions are not pure by default. I guess (did not follow the design discussions), because purity is too limiting. D came up with the concept of "weakly pure", which is useful and strong enough. Also you need transitive const to turn a weakly pure into really pure function.

    import std.c.stdio;

    int main() {
	int x = 7;
	int* p = &x;
	 printf ("%d\n", *(p + 1));
	return 0;
    }

If you prefer a documentation answer(https://dlang.org/spec/arrays.html#pointers) These are simple pointers to data, analogous to C pointers. Pointers are provided for interfacing with C and for specialized systems work. There is no length associated with it, and so there is no way for the compiler or runtime to do bounds checking, etc., on it.

    import std.stdio;

    @safe int f() {
      int* x = new int(6);
      delete x;  // !!
      return *x; // !!!!
    }

    @safe void main() {
      writeln(f());
    }