@trusted attribute should be replaced with @trusted blocks
Joseph Rushton Wakeling
joseph.wakeling at webdrake.net
Thu Jan 16 18:08:20 UTC 2020
On Thursday, 16 January 2020 at 15:45:46 UTC, Steven
> In fact, because of how the system works, @safe code is LESS
> likely to mean what you think.
I'm not quite sure I follow what you mean here, can you
> If you see a @safe function, it just means "some of this is
> mechanically checked". It doesn't mean that the function is so
> much more solid than a @trusted function that you can skip the
> review. It can have trusted escapes that force the whole
> function into the realm of needing review.
Yes, agreed. And hence why your proposal for how to improve
@trusted really makes sense.
> If we moved to a scheme more like I was writing about in the
> post you quoted, then they actually do start to take on a more
> solid meaning. It's still not fool-proof -- @safe functions can
> call @trusted functions, which can call @system functions. BUT
> if everyone does the job they should be doing, then you
> shouldn't be able to call @trusted functions and corrupt
> memory, and you should not have to necessarily review @safe
Yes, this was exactly how I interpreted your proposal.
> There are still cases where you still have to review functions
> that are @safe which do not have inner functions that are
> trusted. These are cases where data that is usually accessible
> to safe functions can cause memory problems in conjunction with
> trusted functions. When you need to break the rules, it's very
> hard to contain where the rule breaking stops.
For example, in a class or struct implementation where a private
variable can be accessed by both @safe and @trusted methods ... ?
More information about the Digitalmars-d