DIP1028 - Rationale for accepting as is

[JN]

On Saturday, 23 May 2020 at 12:13:45 UTC, Steven Schveighoffer 
wrote:
>
> What is not fine is having the compiler do it for you so nary a 
> @trusted marking is in sight. I don't really understand the 
> draw of that.
>
> -Steve

I think not only about how @safe mechanically verifiable is an 
advantage, but also @trusted blocks are very greppable so it's 
easy to find "danger zones" in any project.

I briefly skimmed through the discussion and I don't really see 
the issue with @trusted blocks other than the slightly awkward 
syntax. Yes, it's additional effort, but it should be an 
additional effort, so that people try to avoid unsafe code.

In languages like Rust and C# people are used to using unsafe 
blocks whenever interacting with C code, or people build safe 
wrappers over unsafe APIs, which is exactly what would be 
expected in D after these changes.