Simplification of @trusted
jmh530
john.michael.hall at gmail.com
Wed Jun 16 16:40:42 UTC 2021
On Wednesday, 16 June 2021 at 13:25:09 UTC, Steven Schveighoffer
wrote:
> [snip]
>
> If I were to design it today:
>
> - a @safe function could not call @trusted functions that
> gained implicit access to local data (i.e. inner functions, or
> non-static member functions from the same type).
> - a @trusted function would be mechanically checked just like
> @safe, but could have @system blocks in them (where you could
> call @system functions, or do @system-like behaviors).
>
> This at least puts the emphasis on where manual verification is
> required, but still has the compiler checking things I want it
> to check. Most times, I never want to write a fully marked
> @trusted function, because it's so easy to trust things you
> didn't intend to (like destructors).
>
> -Steve
I see what you're saying. I agree the @trusted function with the
@system blocks within them is better than @safe functions with
@trusted blocks, all else equal. The downside is that the only
way to do it without breaking code is to introduce an alternative
to @trusted since @safe checking for @trusted would break code.
However, consider if you can have @safe/@trusted/@system blocks
(such that a @safe block does manual checking). In that case, you
could have something like below
@trusted
{
@safe
{
// some safe code that you want manually checked
//...
@trusted
{
@system
{
// some @system code
}
// some @trusted code using the @system code
}
}
// some other trusted code
}
More information about the Digitalmars-d
mailing list