Simplification of @trusted

[ag0aep6g]

On 17.06.21 12:28, Ola Fosheim Grøstad wrote:
> Indeed. But if you think about C functions that require arrays of zero 
> terminated strings… Ok, you can create a simple @trusted wrapper, but 
> then that wrapper has to check that all the strings are zero terminated, 
> which adds unacceptable overhead. So even in this trivial example the 
> @trusted code has to assume that the provided data structure is correct, 
> and thus it enables @safe code to make correct @trusted code unsafe.

The function you describe simply can't be @trusted. If you need to call 
a function with a zero-terminated string, and you cannot afford to check 
that the string is indeed zero-terminated, then you just can't guarantee 
safety. A function that is not guaranteed to be safe is @system, not 
@trusted.

> It gets even more complicated in real system level programming where you 
> might make a function @trusted because you know that when this function 
> is called no other threads are running. That is an assumption about an 
> invariant bound to time.

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.

If you want to be extra clever and exploit conditions that are not 
guaranteed by the language, then you either have to make sure inside the 
@trusted function that the conditions are actually met, or you settle 
for @system.

[...]
> For true system level programming something like this (or more advanced) 
> is needed for people to use it. Otherwise just slapping @system on all 
> the code is the easier option. There has to be some significant benefits 
> if you want programmers to add visual noise to their codebase.

True system level programming is going to be @system in D. I don't think 
that's much of a surprise.