DIP1028 - Rationale for accepting as is

ag0aep6g anonymous at example.com
Fri May 22 18:11:28 UTC 2020


On 22.05.20 19:07, Atila Neves wrote:
> Personally and initially, I would have preferred it if non-extern(D) 
> declarations were implicitly @system. I understood Walter's argument 
> about special cases and how they're bad, but the thought of them being 
> @safe made me feel, for lack of a better word, "icky".

So the DIP itself wasn't good enough to convince you. Should have 
rejected it then. Walter could have made another, better argued DIP. 
That's how this is supposed to work, isn't it?

> Then I talked to Walter and he pointed out that if those declarations 
> were @system, users would be prevented from calling them from now @safe 
> code. A regular user would probably just slap `@safe:` at the top of the 
> bindings module anyway. Then I realised that I did exactly that with my 
> libclang bindings:
> 
> https://github.com/atilaneves/libclang/blob/5415707fa6072700bdbf21f827567ffa2fd5c424/source/clang/c/index.d#L254 
> 
> 
> "Worse", I made all functions `pure` and all parameters `in` as well for 
> good measure. Why? I wanted to call them from my @safe pure code with 
> `const` arguments. My reasoning at the time was "I trust libclang".
> 
> And so I was convinced that everything being @safe is actually ok, 
> especially because in real life, most C/C++ APIs aren't going to 
> secretly corrupt your code.

Your reasoning is fine when you're dealing with a function that has a 
safe interface. I.e., it can only corrupt your code when it's buggy. 
Then it makes sense so say "I trust the authors". D users do it with 
Phobos. Phobos authors do it with the C standard library. This kind of 
trust is perfectly ok.

Your reasoning is completely wrong when you're thinking about a function 
that doesn't have a safe interface. E.g., C's `memcpy` just isn't safe. 
It doesn't matter whether you trust the authors or not. The user has to 
make sure that the call is correct. Otherwise, `memcpy` will corrupt 
your memory. And `memcpy` is far from the only such function.

I'm positive that Walter is aware of the difference. Judging from this 
post, I'm afraid you might not be.


More information about the Digitalmars-d-announce mailing list