Yet another leak in the sinking ship of @safe

[Steven Schveighoffer via Digitalmars-d]

On 2/18/16 1:30 PM, Timon Gehr wrote:
> 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.

foo(void[] arr)
{
    void[] arr2 = [1234, 5678, 91011];
    arr[] = arr2[0 .. arr.length];
}

-Steve