Discussion Thread: DIP 1035-- at system Variables--Community Review Round 1

Andrei Alexandrescu SeeWebsiteForEmail at erdani.com
Wed Jun 17 15:53:02 UTC 2020


On 6/17/20 11:24 AM, H. S. Teoh wrote:
> On Wed, Jun 17, 2020 at 10:30:52AM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 6/17/20 9:30 AM, Dennis wrote:
> [...]
>>> I thought the whole premise of @safe was that code review is
>>> inadequate for catching memory corruption bugs.
>>
>> Modules that contain @trusted code need to be reviewed manually. We
>> need to make clear in the documentation that it's not only the
>> @trusted bits in the module; it's the entire module. (That is the case
>> independently on the adoption of the DIP.)
> [...]
> 
> This sounds good in theory, but it presents a significant practical
> challenge: in a large codebase like, say, Phobos, to use a familiar
> example, where a significant number of individuals contribute code,
> reviewing an entire module is an onerous task, since one would have to
> do this every time anything in the module is changed. (Without thorough
> review, you cannot say with 100% assurance that a one-line change
> somewhere won't have effects that percolate throughout the module and
> interact in potentially unsafe ways with @trusted code.)

This will remain a problem. Fundamentally a module containing gnarly 
things like tagged unions (e.g. std.variant) cannot be modified naively, 
even if the modified code is @safe. It's nice to have a mechanism to 
help with that, but it's opt-in so the problem remains.


More information about the Digitalmars-d mailing list