On Friday, 22 May 2020 at 17:41:38 UTC, Steven Schveighoffer
wrote:
On 5/22/20 1:07 PM, Atila Neves wrote:
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.
Yes, it can, but not secretly. Just obviously and easily. Note
this function:
https://github.com/atilaneves/libclang/blob/5415707fa6072700bdbf21f827567ffa2fd5c424/source/clang/c/index.d#L861
And so, you are free to pepper your @safe code with dangling
pointers. Sure, you can claim that the C++ library didn't
"corrupt your code", which is the case for ALL libraries if you
use them properly. You did it, you created a dangling pointer,
not the library.
Right. And the point I was trying to make wasn't "look at what I
did, it's cool". No, what I did was dumb. So dumb it took you no
time at all to point out one of my mistakes. My point is that the
result of making declarations implicity @system instead of @safe
would make people just slap @safe on them without really thinking
about it to get their code to compile. Like I did.
The point of @safe is to protect you from corrupting your own
code based on the guarantees that @safe provides.
I agree.
If we don't care about the guarantees of @safe as long as you
are using C libraries, why are we bothering at all with any of
this?
We care. Annotations become explicit. Do I think this is ideal?
No.
BTW, you should fix that invalid attribute, freeing a pointer
is never @safe unless you can guarantee nobody else has a copy
of that pointer (and considering it's passed by value, the
CALLER still has that pointer!)
You're completely right.
