Simplification of @trusted

[ag0aep6g]

On 17.06.21 13:16, Ola Fosheim Grøstad wrote:
> That basically means that all interesting system level code is @system, 
> including all the code that calls it. That also means that you prevent 
> system level programmers from benefiting from language safety checks!?

Yes.

> Here is the problem with that viewpoint, there is no way for the 
> function to prove that the memory it receives has not been freed. So 
> there is in fact no way for the function to ensure that it is @trusted. 
> That applies to @safe functions too. There has to be a contract between 
> caller and callee, those are the invariants that the unsafe code (and 
> safe code) depends on.

It's not a viewpoint. It's how @system/@trusted/@safe are defined.

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`.

> So I strongly disagree with the viewpoint that @trusted cannot assume 
> invariants to hold for the data it receives. That is mandatory for all 
> correct code of some complexity.

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

> For instance, in order to make the dmd lexer @trusted you would then 
> require the lexer to do the allocation itself. If it accepts a 
> filebuffer allocated outside the lexer then there is no way for the 
> lexer to ensure that the sentinels (zeros at the end) are not 
> overwritten by other code.

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.

> That is an unreasonable restriction that makes @trusted and @safe 
> useless. The lexer should be allowed to assume that the invariants of 
> the filebuffer holds when it takes ownership of it. It is difficult to 
> prove without language level unique ownership, but it is unreasonable to 
> make the lexer and everything that calls it @system, just because it 
> accepts a filebuffer object.

I don't mind you thinking that @trusted is useless. It is what it is. If 
you want something different, you'll have to push for change (i.e. nag 
Walter, write a DIP, make DMD pull requests).

Please don't mistake my insistence on the definition of @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.

>> That's also not a valid @trusted function. "It's safe as long as [some 
>> condition that's not guaranteed by the language]" describes an @system 
>> function, not an @trusted one.
> 
> What are the invariants that are guaranteed by the language in a 
> multi-threaded program that calls C code?
> 
> What can you depend on?

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

For details, see the spec:

https://dlang.org/spec/function.html#safe-interfaces
https://dlang.org/spec/function.html#safe-values
https://dlang.org/spec/function.html#safe-aliasing

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.

> Is it at all possible to write a performant 3D game that isn't @system?

I don't know. I would expect that you need some @system code in there. 
But maybe the higher-level abstractions can be @trusted.

[...]
> But that is the signature of a very high level language, not of a system 
> level language. In system level programming you cannot have dynamic 
> checks all over the place, except in debug builds.

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.

[...]
> That makes Rust a much better option for people who cares about safety. 
> That is a problem.

I don't have an opinion on this.