@system blocks and safer @trusted (ST) functions
acehreli at yahoo.com
Sun Jul 25 21:42:16 UTC 2021
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
This thought may be exactly what Steven Schveighoffer or Bruce Carneal
are bringing up anyway. If so, sorry for only now understanding it. :)
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
1) Make @trusted the default
2) Change @trusted's semantics to be safe (i.e. make it the same as
3) Allow @system inside @trusted
4) Strengthen @safe: No @trusted or @system allowed
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
1) Replace @safe keywords with @trusted where the compiler complains.
(No safety lost because @trusted will be behaving exactly like today's
2) Add @system where the compiler complains. This is because all code is
@trusted by default and @trusted is safe.
More information about the Digitalmars-d