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
