@system blocks and safer @trusted (ST) functions

[Paul Backus]

On Sunday, 25 July 2021 at 20:36:09 UTC, claptrap wrote:
> So no that doesn't prove what you say it does, it doesn't mean 
> favouriteNumber needs checking, it means the @system block 
> needs checking. favouriteNumber knows nothing about the array 
> length, to assume it does or it should is bad design.

Strictly speaking, you're right; it is the `@system` block that 
needs checking, not `favoriteNumber`.

However, any time you change `favoriteNumber`, you have to 
*re-check* the `@system` block. From a maintenance perspective, 
this is no different from `favoriteNumber` itself requiring 
manual checking--if someone submits a PR that changes 
`favoriteNumber`, and you accept it without any manual review, 
you risk introducing a memory-safety bug.

The same logic applies to `@trusted` lambdas. Strictly speaking, 
it is the lambda that requires checking, not the surrounding 
`@safe` code. However, any changes to the surrounding code 
require you to *re-check* the lambda, so from a maintenance 
perspective, you must review changes to the `@safe` part just as 
carefully as changes to the `@trusted` part.

The underlying problem in both cases is that the memory safety of 
the manually-checked code (`@system` block/`@trusted` lambda) 
depends on details of the automatically-checked code that are not 
robust against change.