DIP1028 - Rationale for accepting as is

[Atila Neves]

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.