If you needed any more evidence that memory safety is the future...

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 8 March 2017 at 22:38:24 UTC, XavierAP wrote:
> On Wednesday, 8 March 2017 at 21:02:23 UTC, Moritz Maxeiner 
> wrote:
>> [...]
>>
>> The operating word here being "can". The above is semantically 
>> equivalent (assuming the delegate gets optimized out)  to an 
>> unsafe block inside a Rust function. And yes, that's what I 
>> consider hidden unsafe code, and it means that if you call 
>> function `bar` from a @safe function `foo`, `bar` being marked 
>> as @safe does not save you from auditing `bar`'s source code.
>
> Indeed safety isn't transitive as I thought. @safe may call 
> @trusted, which may include any unsafe implementation as long 
> as the external interface does not. I suppose it was decided 
> back at the time that the opposite would be too restrictive. 
> Then truly safe client code can rely on simple trust 
> established from the bottom up originating from systems unsafe 
> code that is at least hopefully long lasting and stable and 
> more tested (even if manually lol).

If the use case has no problem with that kind of trust, indeed. 
Unfortunately even already long established, and presumably 
stable C APIs have tended to turn into horrible nightmares on 
many an occasion. *cough* openssl *cough*, so this will need to 
be something to evaluate on a project by project, dependency by 
dependency basis imho.

>
> If client code, often rapidly updated, scarcely tested and 
> under pressure of feature creep, is written in @safe D, this 
> can still reduce the amount of failure modes.

I don't disagree with that. Writing your own code in @safe has 
considerable advantages (first and foremost personal peace of 
mind :) ). It's just that other people writing their code in 
@safe does not provide you as a potential user of their code with 
any guarantees. You need to either extend those people the exact 
kind of trust you would if they had written their code in 
@system, or audit their code. It does make auditing considerably 
faster, though, since you can search for all instances of 
@trusted and evaluate their internals and how they're being 
interfaced with (i.e. you can omit auditing @safe functions that 
don't call @trusted functions).

>
> Also at least as of 2010 Andrei's book stated that "At the time 
> of this writing, SafeD is of alpha quality -- meaning that 
> there may be unsafe programs [@safe code blocks] that pass 
> compilation, and safe programs that don't -- but is an area of 
> active development." And 7 years later in this forum I'm 
> hearing many screams for @nogc but little love for @safe...

Well, I can't speak for others, but I generally just use the GC 
for most things (which is by definition memory safe sans any 
bugs) and when I do need to step outside of it I use scope 
guards, refcounting, and have valgrind run (the only annoying 
part about valgrind with D is that there are some 96 bytes that 
it always reports as possibly lost and you have to suppress 
that). Also, when I look at the list of things forbidden in 
@safe[1] I don't see anything I actually do, anyway, so the 
current implementation status of safe has so far not been a 
particular concern of mine.

[1] https://dlang.org/spec/function.html#safe-functions