Returning a reference to be manipulated

[Dennis]

On Friday, 14 April 2023 at 10:31:58 UTC, kdevel wrote:
> But in fact it is returned unless it is `return ref`.

When using `return ref`, `return scope`, `scope` etc., you should 
be using the latest compiler and annotate functions you want 
checked with `@safe`. In previous versions, the compiler would 
often conflate `return ref` and `return scope`, and it was also 
inconsistent in whether it would do checks in `@safe`, `@system`, 
and even 'default/unannotated' functions.

Now, it is more consistent, performing checks in `@safe` code 
only.

> I don't get it! Is there any legitimate use of returning a ref 
> such that it outlives the matching argument's lifetime? If not: 
> Isn't this `return ref` completely redundant?

The annotation is needed because the compiler can't always figure 
out what you're doing with a `ref` parameter:

```D
ref int mysteryFunc(ref int x) @safe; // external implementation

ref int escape() @safe
{
     int local; // allocated on stack frame, should not escape 
this function
     return mysteryFunc(local); // is this safe?
}
```

Is this indeed `@safe`? It is, provided that `mysteryFunc` 
doesn't return its parameter `x`. It can be implemented like this 
for example:


```D
ref int mysteryFunc(ref int x) @safe
{
     x++;
     return *(new int);
}
```

But it wouldn't be safe if `x` were returned, so the compiler 
must know about that when it happens, hence `return ref`:
```D
ref int mysteryFunc(return ref int x) @safe
{
     return x;
}
```

Now the compiler can catch that `return mysteryFunc(local)` is 
unsafe. Note that if `mysteryFunc` is a template function, nested 
function, or returns `auto`, then the compiler infers attributes 
automatically, including `return ref`. Then you can still write 
it as `mysteryFunc(ref int x)` and it will automatically be 
treated as `return ref`.