Simplification of @trusted

[Ola Fosheim Grøstad]

On Thursday, 17 June 2021 at 12:06:45 UTC, ag0aep6g wrote:
> It's not a viewpoint. It's how @system/@trusted/@safe are 
> defined.

Ok. But then the definition has some big _real world_ holes in it.

> Part of that definition is that pointer arguments to @safe and 
> @trusted functions must be valid (not freed). If a freed 
> pointer ends up as the argument to an @safe/@trusted function, 
> you have an error in your @system/@trusted code. @safe code 
> can't produce such a pointer, because it can't call `free`.

It can't call free, but since the language does not have a full 
blown borrow checker or isolated ownership pointer types, there 
is also no way anyone can be 100% certain (as in provably correct 
code).

My take on this is that interfacing with C/C++ undermines @safe 
to such an extent that C/C++ interop isn't really as big of a 
selling point as it is made out to be (meaning you have to choose 
either @safe or C/C++ interop). I think that is a problem. If you 
have two big features then you shouldn't have to choose. The 
conception of @safe has to work well for people who write large 
application with lots of C/C++ interop.


> It can assume the invariants that are guaranteed by the 
> language. The language guarantees (and demands) that pointer 
> arguments are valid.

But it does not guarantee anything about the content that is 
being pointed to. That will trip most interesting use cases for 
unsafe code. Just think about an array with memory-offsets.

That definition makes @trusted mostly useless as @safe code can 
clearly change those memory-offsets. That prevents interesting 
high performance ADTs from being @safe, even when they are 
correctly implemented. You actually should think of the the whole 
class as @trusted then.


> I don't know DMD's source very well, so I can't make statements 
> about that piece of code. But it wouldn't surprise me if it 
> can't be validly @trusted. If you provide a concrete example 
> (that is digestible in size), I can give my take on it.

When you ask for the next lexeme the lexer advances a pointer, if 
it hits a zero character it stops advancing.

For this to be @trusted, by the safe-requirements, the lexer 
cannot accept a filebuffer it has not allocated itself, as that 
makes it possible for external code to overwrite the zeros.

That is not an acceptable restriction.

The lexer should only require that the filebuffer invariant of 
unique ownership and no borrowed pointers to hold. Then the lexer 
can add the zero-character at the end of the buffer and it will 
be @safe.

That is the only acceptable take on @trusted in my view. Anything 
more restrictive than this makes @trusted useless.


> @trusted as a defense of it. If @trusted falls short, then we 
> need something better. But you can't just assert that @trusted 
> really means something else beyond what's in the spec, 
> something that isn't backed by Walter or DMD. That just adds to 
> the confusion about @trusted which is already high.

Ok. But then Walter has to provide a clean description of how 
@trusted can work without making _any_ assumptions about 
invariants of datastructures provided through arguments.

It is not realistic. Not at all!

> @trusted functions can assume that they're only called with 
> "safe values" and "safe aliasing" in the parameters.

I don't think this is enough to prevent @safe code from tripping 
up @trusted code as it would prevent many interesting ADTs from 
being implemented efficently. Meaning, you would have to restrict 
yourself to @safe practices (like bounds checks).

> Note that that part of the spec is largely my attempt at 
> pinning down what Walter means by "safe interface". There are 
> certainly still some things missing. But the gist is there, and 
> it has Walter's blessing.

Got it.

> D is both high and low level. At least, it tries to be. High 
> level: garbage collection enables code to be @safe. Low level: 
> You can avoid garbage collection in @system code. DIP 1000 
> tries to make some lower-level code @safe, but it's clearly not 
> a cure-all.

Ok, but it is not _realistic_ to think that D users will not 
write code that they think is _good enough_ for their purpose. 
Since there is no way to verify that they  adhere to idealistic 
principles, it won't happen.

So, you can get Phobos to adhere to it, but basically no other 
libraries will. And applications will most certainly make choices 
on a case-by-case evaluation.

Now, I am not against Phobos being held to a higher standard, it 
should! But there is no way other people will follow those high 
ideals.