Simplification of @trusted

[Alexandru Ermicioi]

On Wednesday, 16 June 2021 at 17:59:19 UTC, IGotD- wrote:
>
> I have a better idea, throw it all out. What is @safe? It's a 
> limitation of operations you can do in D that might cause 
> memory corruption, like pointer casts and such. Wouldn't be 
> enough that the programmer self know about this and do not use 
> those potentially harmful operations? That would be enough 
> according to me but let's say that the programmer doesn't 
> remember what is unsafe/safe. Then a compiler switch that gives 
> a warning would be enough, at least for me.
>
> I couldn't care less about this safe/unsafe and it just gets in 
> the way. It is also clear that despite you want to automate 
> safe code verification, you are unable to do so and the 
> responsibility falls to the programmer anyway. That you are 
> unable to solve how FFI should act (remember the famous DIP 
> 1028) is also a reminder of that.

That is a no go. Why should I leave verification of code to a 
human that is known to fail from times to times?

C has no verification, and what is the result of this? Lot's and 
lots of bugs due to human errors.

One more thing for verification to be present, is that it saves 
me time. I don't have to be extra careful while writing code, and 
certainly won't need to spend more time debugging a bug that 
could be prevented by automatic code verification.