Manu's `shared` vs the @trusted promise

[Timon Gehr]

On 23.10.18 17:37, Neia Neutuladh wrote:
> On Tue, 23 Oct 2018 10:31:25 +0000, Dukc wrote:
> 
>> On Monday, 22 October 2018 at 14:49:13 UTC, Nicholas Wilson wrote:
>>> On Monday, 22 October 2018 at 11:24:27 UTC, Dukc wrote:
>>>> [snip]
>>>
>>> For reading, its a size_t so can be done with atomics, writing OTOH is
>>> a @property that calls a function to reallocate if ned be. Reallocation
>>> obviously needs to be locked.
>>
>> True, but I meant that the very concept of array having a length member
>> violates the strong @trusted rule referred to by the theard author.
>> That's because somebody could make a @safe function to the module
>> defining an array that makes the array unsafe to use (If the array is a
>> struct in DRuntime, that is. I'm not sure about that.).
> 
> Altering the length of a builtin array calls a runtime function
> _d_arraysetlengthT to reallocate it. And they don't have a .tupleof
> property. So builtin arrays are safe.
> 

What he is saying is, you could add some @safe code to the druntime 
module that defines the dynamic array struct. Then, within this code, 
DMD would consider independent assignments to the length and ptr members 
@safe, even though this is not the case. Therefore, @safe is broken in 
druntime.