@system blocks and safer @trusted (ST) functions

[Ali Çehreli]

On 7/25/21 10:43 AM, Joseph Rushton Wakeling wrote:

 > On Sunday, 25 July 2021 at 05:05:44 UTC, Bruce Carneal wrote:
 >> At beerconf I committed to putting forward a DIP regarding a new
 >> syntactic element to be made available within @trusted functions, the
 >> @system block.  The presence of one or more @system blocks would
 >> enable @safe checking elsewhere in the enclosing @trusted function.
 >
 > I'm very happy to hear that.  I think this proposal is an important and
 > useful one, and I have been thinking of volunteering to write a DIP
 > myself on the topic.

In a recent discussion, I learned from you an idea of Steven 
Schveighoffer. Add to that the relayed opinion of an academic to the 
effect of "it is not safe if you can escape out of it." And add to that 
our failed attempt at "safe by default", the following thought formed in 
my mind.

This thought may be exactly what Steven Schveighoffer or Bruce Carneal 
are bringing up anyway. If so, sorry for only now understanding it. :)


The problems:

1) @system by default provides no checking by default

2) @trusted is not checked either

3) @safe is not safe because you can escape easily


How about:

1) Make @trusted the default

2) Change @trusted's semantics to be safe (i.e. make it the same as 
today's @safe)

3) Allow @system inside @trusted

4) Strengthen @safe: No @trusted or @system allowed


Result:

1) We have safe by default because now @trusted is the default and 
trusted is checked by default

2) @safe is actually safe; no embarrassment


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