On Thursday, 17 June 2021 at 16:50:28 UTC, Paolo Invernizzi wrote:
>On Thursday, 17 June 2021 at 16:21:53 UTC, Paul Backus wrote:
>On Thursday, 17 June 2021 at 14:30:58 UTC, Steven Schveighoffer wrote:
>[...]
Consider the following example:
size_t favoriteNumber() @safe { return 42; }
int favoriteElement(ref int[50] array) @trusted
{
// This is memory safe because we know favoriteNumber returns 42
return array.ptr[favoriteNumber()];
}
[...]
> >There is no language change you can make (short of removing @trusted
entirely) that will prevent this situation from arising.
Apart from reviewers asking the author of favoriteElement to assert that the index is appropriate ...
Yes, that's exactly my point. This can't be solved by changing the language, but it can be solved by a good code review process. So we should avoid wasting our time on language-based solutions (like Steven's proposal for @system
blocks in @trusted
functions), and instead focus on how to improve our code review process so that this kind of brittle @trusted
code doesn't slip through.
For example, a review process that enforced the following rules would have flagged favoriteElement
as problematic:
- Every use of
@trusted
must be accompanied by a comment containing a proof of memory safety. - A memory-safety proof for
@trusted
code may not rely on any knowledge about other functions beyond what is implied by their signatures.
Specifically, favoriteElement
violates rule (2). To bring it into compliance, we'd have to either add an assert
to verify our assumption about favoriteNumber
, or find a way to encode that assumption into favoriteNumber
's signature (for example, with an out
contract).