Simplification of @trusted

Paolo Invernizzi paolo.invernizzi at gmail.com
Thu Jun 17 16:50:28 UTC 2021


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:
>
> ```d
> 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()];
> }
> ```
>
> `favoriteElement` has a safe interface. There is no argument 
> you can pass to it from `@safe` code that can possibly result 
> in memory corruption.
>
> However, if you change `favoriteNumber` to return something 
> different (for example, 69), this may no longer be the case. So 
> changes to `favoriteNumber`--a `@safe` function with no 
> `@trusted` escapes--must still be manually reviewed to ensure 
> that memory safety is maintained.
>
> 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 ...

That's exactly the reason behind a review of trusted function, 
you need to check only it's source code.





More information about the Digitalmars-d mailing list