Yet another leak in the sinking ship of @safe

[Timon Gehr via Digitalmars-d]

On 18.02.2016 19:41, Steven Schveighoffer wrote:
> 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

Good point. :)