https://issues.dlang.org/show_bug.cgi?id=24724

elpenguino+D@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |elpenguino+D@gmail.com

--- Comment #1 from elpenguino+D@gmail.com ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=24724

Dlang Bot <dlang-bot@dlang.rocks> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #2 from Dlang Bot <dlang-bot@dlang.rocks> ---
@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

--

https://issues.dlang.org/show_bug.cgi?id=24724

--- Comment #3 from Nick Treleaven <nick@geany.org> ---
> this is not enforced by restrictions on the function body

Why not enforce it at the interface level?

--

https://issues.dlang.org/show_bug.cgi?id=24724

--- Comment #4 from Nick Treleaven <nick@geany.org> ---
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).

--

https://issues.dlang.org/show_bug.cgi?id=24724

--- Comment #5 from elpenguino+D@gmail.com ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=24724

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkorpel@live.nl
           Hardware|x86_64                      |All
                 OS|Linux                       |All

--- Comment #6 from Dennis <dkorpel@live.nl> ---
(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;
}
```

--