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

[XavierAP via Digitalmars-d]

On Wednesday, 8 March 2017 at 21:02:23 UTC, Moritz Maxeiner wrote:
> On Wednesday, 8 March 2017 at 17:40:29 UTC, Brad Roberts wrote:
>> [...]
>>>
>>> You can hide unsafe code in D by annotating a function with 
>>> @trusted the same way you can hide unsafe code in Rust with 
>>> unsafe blocks.
>>
>> Clearly marked is an interesting definition of hidden.
>
> 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 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.

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...