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.
