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