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.
The point of @safe is to protect you from corrupting your own code based
on the guarantees that @safe provides. 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? I'd rather see a DIP that just
removes safety completely if the language maintainers just trust all C
libraries "in real life".
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!)
Will that break your code? It sure might! It just means YOUR code needs
to be marked @trusted or @system as appropriate.
-Steve
