October 23, 2018 Re: Manu's `shared` vs the @trusted promise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Tue, 23 Oct 2018 22:25:55 +0200, Timon Gehr wrote:
> 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.
Yes, the principle is quite reasonable. Anything that can access a non- @safe interface of a thing needs to be carefully vetted to make sure it's valid as @trusted code, and that means looking at a whole module at once. So put your @trusted code in separate modules insofar as possible.
In this particular case, though, druntime functions are generally @trusted rather than @safe, and arrays are defined by the compiler and not as structs in druntime.
|
October 23, 2018 Re: Manu's `shared` vs the @trusted promise | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Tuesday, 23 October 2018 at 20:25:55 UTC, Timon Gehr wrote:
> On 23.10.18 17:37, Neia Neutuladh wrote:
>> 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.
I would have assumed that they would be behind @properties which would be not `shared` (so uncallable on shared slices), and their internal logic would be @trusted.
|
Copyright © 1999-2021 by the D Language Foundation