@system blocks and safer @trusted (ST) functions

[jmh530]

On Sunday, 25 July 2021 at 21:42:16 UTC, Ali Çehreli wrote:
> [snip]
> Existing code:
>
> 1) Replace @safe keywords with @trusted where the compiler 
> complains. (No safety lost because @trusted will be behaving 
> exactly like today's @safe.)
>
> 2) Add @system where the compiler complains. This is because 
> all code is @trusted by default and @trusted is safe.
>
> Ali

I'd much rather add new attributes for new behavior than break 
existing code. If you want @safe to not be able to call @trusted 
functions, then introduce a new attribute with that behavior.

I think too much is trying to get shoehorned into the 
@safe/@trusted/@system dichotomy.

I have favored the whitelist/blacklist approach that had been 
discussed on the forums previously (ignoring bikeshedding on 
names). @whitelist would only allow operations known to be memory 
safe (so no @trusted escape hatch). @blacklist would be the 
opposite of what is currently @safe, in that things that are not 
allowed in @safe would have to be in a @blacklist function (or 
block). This would contrast with @system, which basically allows 
everything in them. Unmarked @system functions would be assumed 
to be @blacklist, unless they can be inferred to be @whitelist.

Whether @whitelist is orthogonal to @blacklist (such that 
everything that is not @whitelist must be @blacklist), I am not 
100% sure on, but I would lean to putting things in @blacklist 
only if they are not allowed in @safe currently, which may allow 
for a middle ground. Regardless, a @whitelist function can only 
call @whitelist functions. A @blacklist function can call any 
kind of function it wants.

@safe functions would be able to call @whitelist functions, but 
nothing would stop them from calling @trusted @blacklist 
functions. @trusted or @system functions could call either 
@whitelist or @blacklist functions (the use of these might make 
it easier to narrow down where safety issues are). However, if 
either @safe/@trusted/@system functions call @blacklist functions 
(or include blocks) then they become @blacklist (either 
explicitly or inferred). So this would distinguish an @safe 
function that is @whitelist from one that is @blacklist. An @safe 
function that is @whitelist is verified by the compiler not to 
only use operations that the compiler verifies are memory safe, 
while one that is @blacklist will have at some point called 
@trusted functions that use @blacklist behavior and needs to be 
manually verified.

This approach doesn't break any code and allows for a lot of the 
flexibility that I think people want with the @safe system.