DIP1028 - Rationale for accepting as is

[Steven Schveighoffer]

On 5/25/20 5:17 AM, Walter Bright wrote:
> On 5/23/2020 5:13 AM, Steven Schveighoffer wrote:
>> And let's be honest here, if you are OK with it, putting @trusted: at 
>> the top of your extern(C) functions is fine with me. At least that's 
>> not a lie.
> 
> @trusted says the interface to the function is safe. If the programmer 
> did not actually check the interface, it is greenwashing. For example, 
> memcpy() does not have a safe interface and marking it @trusted doesn't 
> improve matters.

Yes, and the programmer did this on purpose. To quote someone else `My 
reasoning at the time was "I trust libclang".` In that sense, it's not a 
lie, or "incorrect," you are just trusting that whomever wrote that C 
library (maybe it was the author of the prototype) followed strictly the 
D safety rules. It's possible to write a function that takes 2 pointers 
and a size_t that is @safe, just like memcpy (it won't do anything, but 
there is nothing inherently wrong with that). If it were possible to 
determine directly from the types of parameters that a function wasn't 
safe, we would not be having this discussion.

So "trusting" a library regardless of interface is what @trusted: does. 
And while I wouldn't do that, or use a library that does that, at least 
I can see where the problem is! @trusted code is hard to write 
correctly, and there's going to be greenwashing abound when this change 
comes about. I can even envision someone *recommending* "Don't import 
core.stdc.x, just declare the prototype yourself, and you can then call 
them from safe functions!".

Greenwashing by the compiler essentially adding @trusted to every C 
porototype doesn't make it any better. I'd much rather have a clear 
indication that someone made this conscious decision, correct or not, 
and here is where you should look to find the problems. If I am 
interested in ENSURING that all code I use is @safe or correctly 
@trusted, then I know how to find those points of contention if the 
@trusted attribute is required where it should be.

The biggest problem with the magic greenwashing of this DIP is that 
there is 10-20 years of existing D code with extern(C) function 
prototypes that are specifically unmarked BECAUSE the author knew that 
meant @system. I don't know how this DIP can be approved just on that 
problem alone.

I hope something better comes out of this discussion, I'm going to mute 
it now because I don't have the time to keep arguing against people who 
don't seem to understand either memory safety or human nature.

-Steve