Yet another leak in the sinking ship of @safe

[Timon Gehr via Digitalmars-d]

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.