memory safety checks and trust

[Timon Gehr]

On 13.04.20 09:50, Walter Bright wrote:
> 
>> But like Adam I don't see why there should be such a check in 
>> @system/@trusted code at all. (I understand that there is a 
>> workaround, but that should not be required.)
>>
>> Can we please settle on making @safe actually memory safe and 
>> @system/@trusted actually trust the programmer?
> 
> Consider:
> 
>    @system int* pumpkin(int i) { return &i; }
> 
> Should that give an error or not?
> ...

I don't see why not.

> I.e. where does one draw the line?

I think D has been in a pretty good place for a quite long time. Beyond 
straightforward parser/type system diagnostics that you can disable 
using explicit parentheses/type casts, only diagnose cases that have no 
legitimate use. You might not get this right, so it's probably a good 
idea to be open to the idea of removing/restricting diagnostics when 
people complain on the forums that their perfectly valid 
@system/@trusted code was rejected.

In @system/@trusted code, if you diagnose, the code should usually be 
wrong and if it is not, the workaround should have the same behavior as 
if the diagnostic had not been there in the first place (e.g., don't 
slow down debug builds).