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
