Simplification of @trusted

[ag0aep6g]

On Thursday, 17 June 2021 at 22:03:47 UTC, Paul Backus wrote:
> However, if we assume for the sake for argument that @safe code 
> *can't* bypass `private`, then it is possible to prove that the 
> invariant `offset < 2` is maintained by examining only code in 
> the module where `offset` is defined. And once we've proven 
> that invariant, we can prove that `get` is always memory safe 
> when called from `@safe` code.

Not when new (@safe) code is added to the same module. E.g., the 
new guy adds an @safe method that has the bug from Ola's original 
code (`offset = 2;`).

> I will grant that, even in this hypothetical, `get` still would 
> not satisfy the definition of "safe interface" currently given 
> in the language spec--but at that point, who cares? The current 
> definition is valid for the current language, but if the 
> language changes, the definition ought to be updated too.

If the spec is ever changed to say that an @trusted function 
taints the module it's in, then sure. But until that happens, I 
maintain that @trusted code is not allowed to rely on an external 
integer for safety, including private ones.

I'm not saying that that's the best way to define @trusted. But I 
believe that it's in our best interest to acknowledge the spec, 
and that no one really bothers  following it. That way everyone 
is on the same page (we don't need any more confusion when it 
comes to @trusted), and it gives DIP 1035 and other proposals 
more oomph, because it's clear that the status quo isn't good 
enough.

If everyone pretends that the spec agrees with their personal 
take on @trusted, then there is no perceived need to fix 
anything. People with slightly different interpretations will 
keep talking past each other. Newbies will keep having a hard 
time.