On Thursday, 19 May 2022 at 09:57:47 UTC, Dennis wrote:
> You get the same inference as a non-@trusted
function, it stops at the exact same point (i.e. as soon as aliases are created).
Yes. But the point is, AFAIK it is implementation-defined how far a compiler will take checks like this. For example, this code:
@system int* wrong()
{ int local;
return &local;
}
...fails with DMD. But this is an implementation-defined error. Nothing in the spec says a compiler must check for this, and nothing in the spec says that the checks cannot be taken further than what DMD currently does.
A little unportable, but reasonable. You can have helper functions like the one you just posted for cases like this, that are easy to port from one compiler to another in centralised fashion.
But if such implementation-dependent checks cause the same function to compile with different semantics, then it's a problem. A @trusted function might infer return scope
of a parameter on one compiler and work well, but suddenly stop doing so for another. Then you have cryptic errors in another part of the application. Or even worse, you might escape pointers in the future due to the checks working differently than when you last tested them.