@trusted attribute should be replaced with @trusted blocks

[Joseph Rushton Wakeling]

On Saturday, 18 January 2020 at 21:44:17 UTC, David Nadlinger 
wrote:
> On Thursday, 16 January 2020 at 00:21:21 UTC, Joseph Rushton 
> Wakeling wrote:
>> The fact that in a similar situation D forces you to annotate 
>> the function with `@trusted`, and alert users to the 
>> _possibility_ that memory safety bugs could exist within the 
>> code of this function, is useful information even if you can't 
>> access the source code.
>
> Detail the scenario where this would be useful, please.

I'm honestly not sure what is useful to add to the existing 
discussion.  But I think the problem is that most folks are 
looking for certainties, whereas I'm prepared to entertain a 
certain amount of probability in certain contexts.  (Please read 
on to understand what I mean by that, rather than assuming that 
I'm prepared to allow memory safety to be a roll of the dice:-)

Put it like this: for any given @safe function you see, odds are 
that in practice it uses no @trusted code outside the standard 
library/runtime.  Is that a guarantee?  No.  But it's a 
reasonable heuristic to use on a day-to-day "How concerned do I 
have to be that this function might do something scary?" basis.  
(Depending on what the function does, I might be able to make an 
educated guess of the likelihood there's something @trusted 
closer to home.)

OTOH if I see a function marked as @trusted I have a cast-iron 
guarantee that the compiler did not do anything to verify the 
memory safety of _this particular function_.  Which gives me a 
nudge that on the balance of probability, I might want to give a 
bit more up-front scrutiny to exactly what it's doing -- either 
by reading the source code if I can, or by playing with it a bit 
to see if I can trip it up with some unexpected input.

Is that an _audit_?  No.  But it doesn't seem vastly different to 
the kind of day to day trust-versus-verify judgement calls that 
we all have to make, on a day to day basis, about all sorts of 
matters of code correctness in the APIs that we use.

> If you want to audit a program to make sure there are no uses 
> of potentially memory-unsafe code, you need access to all the 
> source code

Yes, agreed.  But that's the difference between doing a full 
safety audit versus the typical day-to-day "Does it seem 
reasonable to use this function for my use-case?" judgement calls 
that we all make when writing code.