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