New @safe rule: defensive closures

[Dukc]

On Saturday, 28 May 2022 at 10:24:40 UTC, Ola Fosheim Grøstad 
wrote:
> On Saturday, 28 May 2022 at 08:12:53 UTC, Dukc wrote:
>> Good brainstorming. But I don't think it can work:
>
> The root cause is that Walter does not want @safe to be a high 
> level feature, as a result it will be easier to write @system 
> code than @safe no matter what features he comes up with!!

`@safe` code is almost always higher level than `@system` code on 
average. In both theory and practice.

You are right in the sense that you can do everything in 
`@system` that you can do in `@safe` and more, so it's more 
expressive and higher level in the same sense C90 is 
"higher-level" than C99. And just like it may not be worth it to 
add proper function prototypes to already well-tested C90 
codebase, it's not always worthwhile to add `@safe` to D a stable 
D codebase that is not going to see any major refactoring.

But woe to one who chooses `@system` just to "be higher level". 
While it does enable slightly shorter code in some cases, much 
more time will be lost debugging the error-prone practices it 
leads to. It's just as "good" choice as not using function 
prototypes in a new C codebase because it saves some LOC.