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