@system blocks and safer @trusted (ST) functions

[claptrap]

On Sunday, 25 July 2021 at 17:47:40 UTC, Paul Backus wrote:
> On Sunday, 25 July 2021 at 16:29:38 UTC, Bruce Carneal wrote:
>> Machine advantage comes in other forms.  Firstly, we now have 
>> a properly segregated code base.  @safe always means 'machine 
>> checkable'.  Zero procedural @trusted code review errors in 
>> that now easily identified class.
>
> I have already demonstrated that this is false. Here's my 
> example from the previous thread on this topic, rewritten 
> slightly to use the new-style `@trusted`/`@system` syntax from 
> your proposal:
>
> ```d
> module example;
>
> size_t favoriteNumber() @safe { return 42; }
>
> int favoriteElement(ref int[50] array) @trusted
> {
>     // This is memory safe because we know favoriteNumber 
> returns 42
>     @system {
>         return array.ptr[favoriteNumber()];
>     }
> }
> ```
>
> I make the following claims:
>
> 1. This code is memory-safe. No matter how you call 
> `favoriteElement`, it will not result in undefined behavior, or 
> allow undefined behavior to occur in `@safe` code.
> 2. `favoriteNumber` is 100% machine-checkable `@safe` code.
> 3. Changes to `favoriteNumber` must be manually reviewed in 
> order to ensure they do not result in memory-safety violations.

So...

Call a safe function and get an int.
Use that int to index into an array with bounds checking turned 
off.

Wheres the memory safety bug? In the function that returns the 
int or in the system code that bypasses bounds checking?

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.