Hacker News new | past | comments | ask | show | jobs | submit login

> D is a great, modern, safe language

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




It's close, and we're working to close the remaining gaps.

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


I wonder, could a portable ownership model be implemented with the templates?


Not soundly, no. The borrow check requires flow-sensitive analysis. The lifetime typechecker requires subtyping-aware extensions to Hindley-Milner.


Can you going into some details about this? Like proofs?


I thought there was a DIP for this, but cannot seem to find it now.


When is D not memory safe?


It has been years since I have actively programed in D, so take this with a grain of salt, but my understanding is that D only guarantees memory safety in its @safe subset. See here: https://dlang.org/spec/memory-safe-d.html

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)


Yes, Rust picked the better default and D is too mature to change it now, unfortunately. Likewise with "pure", "const", and maybe even "nothrow" and "nogc".

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.



By default, D has no safeguards to prevent you from doing memory-unsafe things, and afaik no compile-time checks short of marking your main method as @safe. However, because the language is by default memory managed, it is fairly easy to stick to safe code without this by avoiding pointer/cast voodoo.


Fortunately with array bounds checks and default initialized variables, memory corruptions aren't very common in D.


Always:

    import std.c.stdio;

    int main() {
	int x = 7;
	int* p = &x;
	 printf ("%d\n", *(p + 1));
	return 0;
    }
This compiles in D and violates memory safety.

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.


Add '@safe' to main()'s declaration and it will no longer compile.


    import std.stdio;

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

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


'delete' is in the process of being deprecated: https://dlang.org/deprecate.html#delete




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: