On 18.02.2016 17:37, H. S. Teoh via Digitalmars-d wrote:
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
No problem here. There is no way to assign to a void[] without doing 2.
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
This is the culprit.
