DIP1028 - Rationale for accepting as is

[ag0aep6g]

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