@trusted attribute should be replaced with @trusted blocks
schveiguy at gmail.com
Thu Jan 16 16:06:05 UTC 2020
On 1/16/20 10:46 AM, Ola Fosheim Grøstad wrote:
> On Thursday, 16 January 2020 at 15:30:45 UTC, Steven Schveighoffer wrote:
>> The second is how much manual review is needed for the code. This is a
>> signal to the reviewer/reader. In the current regime, the two reasons
>> for marking are muddled -- we don't have a good way to say "this needs
>> manual checking, but I also want the benefits of mechanical checking".
>> This is why I proposed a change to trusted code STILL being
>> mechanically checked, unless you want an escape. This would allow you
>> to mark all code that needs manual review trusted, even if it's
>> mechanically checked (it still needs review if the system-calling
>> parts can muck with the data).
> As was pointed out @trusted does not achieve much more than a comment,
> so why not just have a statement- / operator-level escape using a
> distinguishable and greppable marker like @@. Then you can just prepend
> that to all function calls or operations that are unsafe:
> ptr = …
> //TRUSTED: this is safe because x, y, z
> Then leave on any existing mechanical checks and keep adding @@ until it
Enforcing the name of the comment helps the greppability. And putting
@trusted on the entire function helps avoid grep finding blocks whereby
you now have to dig back up to find the context.
@safe functions with no trusted escapes have a much different level of
review required. If you can assume all the inputs are valid, then the
function shouldn't need review -- even if it calls trusted functions.
I was looking for a distinction from @safe functions like this, and
@safe ones with escapes.
I do like the @@ syntax, though @system free(ptr); isn't much worse.
More information about the Digitalmars-d