1. 7
    1. 4

      to a memory safe programming language, D,

      Memory safer language. As of 2.100.2, D is very much not a memory safe language, as it is trivial to get UB using out-of-the-box config

      $ dmd --version
      DMD64 D Compiler v2.100.2
      
      $ cat main.d 
      import std.stdio;
      
      void main(){
          auto r = f();
          writeln("hello, ub");
          writeln(*r);
      }
      
      auto f() {
          int x = 92;
          return g(&x);
      }
      
      auto g(int* x) {
          return x;
      }
      
      $ dmd main.d && ./main
      hello, ub
      4722720
      
      1. 3

        You must have missed the part about the @safe attribute:

        ; cat main_safe.d
        import std.stdio;
        
        @safe:
        
        void main() {
            auto r = f();
            writeln("hello, ub");
            writeln(*r);
        }
        
        auto f() {
            int x = 92;
            return g(&x);
        }
        
        auto g(int* x) {
            return x;
        }
        
        ; dmd main_safe.d
        main_safe.d(13): Error: cannot take address of local `x` in `@safe` function `f`
        

        D is far from perfect, but it’s not as trivial as you say :)

        1. 4

          I think the part about out-of-the-box is important: if I need to opt-in into safety, how can I know that I sufficiently opted-in? Safe not being the default also signals to me that, for practical purposes, @safe D isn’t expressive enough.

          Looking at the code, the pattern seems to be that smaller functions are @safe, while the larger ones are not.

          I guess, my thinking is:

          • safe being default is a strong signal that the language takes safety seriously
          • it can be argued that, even with opt-in safety, a language can be considered safe, but that increases the burden of proof (or rather, the burden of explanation to non-experts) significantly
          • explanations so far does seem to point that D is not actually practically safe: if I can’t even take an addres of local in safe code, what can I do in safe code which I can’t do, in, eg, Go? Looking at the example code does not inspire confidence either.
        2. 3

          A language where you have to explicitly opt into memory safety is not a memory safe language.

      2. 2

        Yeah, I think the authors misspoke there. I think Walter Bright would probably agree with you. I think its safe to say that D, even in better C mode which they’re using, is safer than C, but to full on call it memory safe is an overstep.

    2. 2

      This is a neat article. I’m glad to see to people using D for things like this. I think it would an improvement over C in a lot of ways, but I think its safe to say its not a large enough leap to justify writing thousands of lines of code of D instead C - and now rust of course.

    3. 1
    4. 1

      I’m really fond of this language so I could see the benefits in writing in D here, also not to mention the metaprogramming capabilities.