DIP1028 - Rationale for accepting as is

[Steven Schveighoffer]

On 5/22/20 1:52 PM, jmh530 wrote:
> On Friday, 22 May 2020 at 16:47:34 UTC, Steven Schveighoffer wrote:
>> [snip]
>>
>> You can't, you don't control that code, someone else does (this is 
>> important, you can declare extern(C) functions anywhere, even locally).
> 
> You can make a separate module with one function that just calls the 
> `free` function and has the @system attribute. Then, just change the 
> import for the free function to that new module. Annoying, but 
> potentially fix-able.

You are using library fubar.

fubar defines a function foo:

void foo(int *p)
{
    import fubar.cfunctions : free;
    free(p);
}

After this DIP, it now becomes completely assumed @safe. The author of 
fubar intended it to be @system. But now all safe code can now call it, 
and there's nothing you can do except ask them to fix both modules to be 
@system. You can just stop using the library, sure. But you have no 
control over whether fubar's code is properly written. That is the point.

If the C prototype was instead considered @system, then foo stops 
compiling (for good reason), and you can either motivate the author to 
fix it, or use a different library. But at least you can't ACCIDENTALLY 
use it in @safe code.

Essentially all code written before this DIP is switched on is 
completely suspect, and needs manual verification -- if you care about 
safety at all.

-Steve