DIP 1028---Make @safe the Default---Community Review Round 1

[Arine]

On Thursday, 9 January 2020 at 00:49:29 UTC, H. S. Teoh wrote:
> On Thu, Jan 09, 2020 at 10:12:23AM +1000, Manu via 
> Digitalmars-d wrote: [...]
>> unsafe blocks is distinctly preferable to me. Functions are 
>> usually >1 line, and I hate that we can only mark this at the 
>> function level. Unsafely statements are never at the function 
>> level, it's usually just one line among a larger function. An 
>> unsafe scope would be immensely preferable to me, because I 
>> can make it as narrow as the code i'm suspicious of, and the 
>> surrounding code doesn't lose its safe checking just by being 
>> a bystander.
>
> There is this current idiom that essentially serves as a 
> @trusted block:
>
> 	auto myFunc() @safe {
> 		... // mundane stuff
> 		() @trusted {
> 			// dangerous stuff goes here
> 		}();
> 		... // more mundane stuff
> 	}
>
> But it's quite the eyesore, I'll admit.
>
> OTOH, that may be its redeeming quality: it looks so ugly, and 
> is so icky to write, that it discourages people from overusing 
> it. You're inclined to do it only when you absolutely have to.

This isn't something you'd want people to not write. It's how you 
are expected to write it in C# and Rust (without the lambda 
obviously). It makes it easier to read because you see in the 
@safe function what is unsafe. Creating a separate function that 
you probably don't need, and labeling it as @trusted just makes 
the code harder to read and understand what might be unsafe. You 
have to go through the entire function, call by call and 
determine which functions are unsafe.