While @safe is a good idea in principle, the current implementation is
rather lackluster. Consider, for example:

        void readData(void[] buffer) @safe
        {
                ubyte[] buf = cast(ubyte[]) buffer;
                buf[0] = 0xFF;
        }
        void main() @safe
        {
                auto buffer = new Object[1];
                readData(buffer);
        }

There are (at least) two major problems here:

1) Casting an array of elements with indirections (in this case
Object[]) to void[] is questionable at best, outright unsafe at worst,
as shown here. Even if we were to rewrite readData() and mark it
@trusted, it still raises the question of what a @trusted function can
legally do with void[], which is essentially a type-erased array, that
justifies being tagged as @trusted.  How can a function do anything that
doesn't break @safety if all type information about the array has been
erased, and it essentially sees it only as a ubyte[]?  I'm inclined to
say that @trusted functions should only be allowed to receive
const(void)[] as parameter, not void[].

        https://issues.dlang.org/show_bug.cgi?id=15702

2) To add salt to the wound, though, blatantly casting void[] to T[] is
allowed in @safe code, thus, readData() can even get away with claiming
to be @safe, when in fact it is anything but.

        https://issues.dlang.org/show_bug.cgi?id=15672

These two issues basically make the @safe annotation an empty promise,
because *anything* could happen entirely within the realm of @safe code,
and memory safety isn't guaranteed at all.  It's bad enough that some
Phobos modules (*ahem*std.socket*cough*) liberally sprinkle @trusted on
every function without regard to whether it's truly justified (e.g., see
https://issues.dlang.org/show_bug.cgi?id=15672), now even if we exclude
@trusted functions from the mix, we can still break @safe without the
compiler even raising an eyebrow.

Sadly, the above issues are merely the tip of the iceberg. There are
many more holes in @safe, such as unions containing pointers, unions of
@safe and @system delegates, unaligned pointers, void initialization of
members with indirection, just to name a few.  If we want the @safe ship
to float, we have a lot of work cut out for us.


--T

Reply via email to