Bug 24724 – Error when @trusted function returns reference to parameter

@trusted ref int a(ref int r) { return r; } @trusted int* b(ref int r) { return &r; } The above functions violate the @trusted requirement of having a safe interface, so these should both error on their return statements. The `return` attribute is a requirement for a safe interface when a `ref` parameter may escape. Otherwise, those functions should be @system (then no error is needed). PR incoming. Note the following are errors even in @system code: @system ref int c(int r) { return r; } @system int* d(int r) { return &r; }

https://dlang.org/spec/function.html#trusted-functions "Like safe functions, trusted functions have safe interfaces. Unlike safe functions, this is not enforced by restrictions on the function body." We have a method to enforce safe interfaces. It's @safe.

@ntrel created dlang/dmd pull request #16814 "Fix Bugzilla 24724 - Error when @trusted function returns reference t…" fixing this issue: - Fix Bugzilla 24724 - Error when @trusted function returns reference to parameter Make it a deprecation for now. https://github.com/dlang/dmd/pull/16814

> this is not enforced by restrictions on the function body Why not enforce it at the interface level?

In what scenario is allowing @trusted to have an unsafe interface useful? A single example will suffice, please provide one (that can't be @system).

(In reply to Nick Treleaven from comment #3) > > this is not enforced by restrictions on the function body > > Why not enforce it at the interface level? We do. With `@safe`. `@trusted` is specifically for manual enforcement. (In reply to Nick Treleaven from comment #4) > In what scenario is allowing @trusted to have an unsafe interface useful? A > single example will suffice, please provide one (that can't be @system). The compiler can't prove all memory-safe code is memory-safe, only a subset. It is occasionally useful to call manually-verified code from `@safe` functions, which `@trusted` enables. There is no other value to it. Adding enforcement to it removes that value, and reduces it to just a carbon copy of `@safe`. I'd rather see `@trusted` removed entirely than go down that path.

(In reply to Nick Treleaven from comment #4) > In what scenario is allowing @trusted to have an unsafe interface useful? A > single example will suffice, please provide one (that can't be @system). The interface is not necessarily unsafe. The example you gave is trivial, but the return statement may be unreachable or guarded like so: ``` @trusted int* b(ref int r) { if (isInDataSegment(&r)) return &r; else return null; } ```

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/20500 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB