DIP1028 - Rationale for accepting as is

[Steven Schveighoffer]

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