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 :)
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.
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.
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.
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
You must have missed the part about the
@safeattribute:D is far from perfect, but it’s not as trivial as you say :)
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:
A language where you have to explicitly opt into memory safety is not a memory safe language.
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.
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.
code
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.