Simplification of @trusted

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Thu Jun 17 21:10:25 UTC 2021


On Thursday, 17 June 2021 at 20:57:27 UTC, ag0aep6g wrote:
> You mean if it holds a different value, then the program 
> becomes invalid? Sure, that's easy to prove. Do you expect the 
> compiler to do that proof, and then give you an error when you 
> violate the invariant? That's not at all how D works.

I mean that this should satisfy the requirements (fixed a bug 
that allowed ptr to be changed after construction):

```d
class A {

     this() @trusted {
         ptr = &buffer[0];
         offset = 0;
     }

     int get() @trusted { return ptr[offset]; }
     void set(int i) @trusted { this.offset = i&1; }
     int size()@trusted{ return 2;}
private:
     int[2] buffer;
     const(int*) ptr;
     int offset;
}
```

1. There is no way for @safe code to make this unsafe.

2. I have through audit proven that all methods keep offset 
within the required range.


> The point of manually auditing @trusted is to ensure that the 
> function actually follows the requirements.

Then the requirements need to be made more explicit, because 
people seem to disagree as to what is required.

> variables in a library. What people actually do is ignore the 
> rules and live the dangerous lifes of safety outlaws.

No, that is not what I want. I want to define the necessary 
invariants to uphold safety. Then prove that my class remains 
within the constraints.

Yes, preventing @safe code from writing to some variables might 
make that task easier. In the meanwhile I can just make all 
methods @trusted.

> You can do that with @system. @safe and @trusted won't help 
> enforcing your custom invariants.

But @trusted requires you to manually audit the invariants 
needed, so why force a weakening of the invariants that are 
needed to make it safe? That makes no sense, if you already are 
required to conduct a manual audit. The compiler has no say in 
this either way.

People will do it, and they will be correct and sensible for 
doing so. By requiring an audit _we already presume that the 
auditor has the required skillset_ to reason about these issues 
at a formal level!






More information about the Digitalmars-d mailing list