On 22.05.20 20:24, Atila Neves wrote:
On Friday, 22 May 2020 at 18:11:28 UTC, ag0aep6g wrote:
So the DIP itself wasn't good enough to convince you.
Had that been the case, I would have rejected it.
You said the DIP as written felt "icky". And only after a chat with
Walter did that feeling go away. You're saying you would have accepted a
DIP that feels icky? DIPs are supposed to be convincing, not barely
tolerable.
memcpy isn't a good example since it's explicitly @system:
https://dlang.org/phobos/core_stdc_string.html#.memcpy
core.stdc.string.memcpy is a specific binding to C's memcpy. Any other
declaration of it will be implicitly @safe.
"But why would anyone declare `memcpy` themselves, when they can just
import the one from `core`?" I hear you ask. And I answer:
1) Shouldn't matter, if we're talking about a principled safety system.
But I realize that the leadership isn't interested in that anymore.
2) I have quickly typed out C declarations before, because it was more
convenient than looking up where it is exactly in the standard library.
And we're all about catering to convenience now, aren't we?
Yes. But most of them aren't like memcpy. Most D code calls other D
code, not C.
Most D code isn't behind an `extern (C)` prototype. Virtually no one is
(strongly) against making D functions @safe by default.
Am I saying nothing bad can happen if we implicitly trust extern(C)
declarations? No. I'm saying we'll be no worse off if they're all
implicitly @system.
"No worse off" should not be good enough for a DIP.
This compiles with no warnings right *now*:
void main() {
import core.stdc.stdlib: free;
free(cast(void*) 42);
free(new int);
free(&main);
}
And this doesn't compile right now, but it will with DIP 1028:
----
extern (C) void free(void*);
void main() @safe {
free(cast(void*) 42);
free(new int);
free(&main);
}
----
Yes, yes, I know. That's soo much less common in the real world. But
before the great @safe schism that is happening right now, @safe wasn't
about catching more bugs than not on average. It was about being "100%
mechanically checkable" (Walter's words).
I for one liked it better when it had that aspiration. And I was
contributing towards that goal (latest PR was merged just yesterday,
coincidentally [1]). I have no interest in a version of @safe that is
deliberately fuzzy, where I have to defend safety fixes against
convenience arguments.
[1] https://github.com/dlang/dlang.org/pull/2773
