Simplification of @trusted

[Ola Fosheim Grøstad]

On Thursday, 17 June 2021 at 13:19:01 UTC, Mathias LANG wrote:
> Wat ? That doesn't make any sense. A function that would free 
> its input *has to be @system*.

Yes, but that was not the point.

If you call C-code, it may release a pointer deep down in the 
datastructure without setting the pointer to NULL. The invariant 
ensures that it isn't used.

Then you call D, and D claims that the pointer has to be null or 
you break @trusted , even if you never dereference?

Also, it claims that you cannot make assumptions of size, which 
would be an invariant (e.g. a size field would be tied to an 
invariant). This is not a language level guarantee, so it cannot 
be used...

> Anything that deals with an array of memory offset needs to be 
> encapsulated in its own data structure. `@safe` is about 
> exposing a `@safe` interface, that is, something that can't be 
> misused. If you use an array of memory offsets, then you have 
> to do pointer arithmetic, which is not `@safe`.

But this is not enough. As @trusted apparently requires you to 
assume that the datastructure can be filled with garabage and 
using it should still always be @safe? Otherwise you assume that 
invariants hold.


> You *can't* mark a function as trusted if it accepts an array 
> of memory offset and just uses it. And you can't call that 
> "correctly implemented", either.

Why not? It is protected by private. You CAN if you only access 
it with @trusted memberfunctions. However if you have one  @safe 
memberfunction then a bug in that one could accidentally modify 
the offsets.

As a consequence you can ONLY have @trusted member functions, not 
even a single @safe member function, that does nothing can be 
allowed. As it could in theory contain a bug that could change 
the offsets.

Or, where am I wrong now?