Returning a reference to be manipulated

kdevel kdevel at vogtner.de
Sat Apr 15 13:52:18 UTC 2023


On Saturday, 15 April 2023 at 13:24:52 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> On 16/04/2023 1:20 AM, kdevel wrote:
>> On Saturday, 15 April 2023 at 12:45:31 UTC, Richard (Rikki) 
>> Andrew Cattermole wrote:
>>> It was bad analysis by the compiler, which has since been 
>>> corrected.
>>>
>>> It should have been applied only to @safe code.
>> 
>> But why is the @unsafe programmer now left unprotected in 
>> cases like this
>> 
>> ```
>> ref int foo (ref int i)
>> //           `------- automatically insert `return` here?
>> {
>>     return i;
>> }
>> ```
>> 
>> where the compiler recognizes that the function returns a ref 
>> parameter?
>> 
>> Under which circumstances is it a mistake to insert the 
>> `return` at the indicated position? If there are none why 
>> can't it be done implicitly (automatically)?
>
> @system (which is currently the default, there is a strong 
> desire to change this), does no safety checks.

When I insert `return` before `ref int` and compile the code dmd 
says

```
returnref2.d(9): Error: returning `foo(i)` escapes a reference to 
local variable `i`
```

Isn't this a safety check? (The code does not contain any `@`.)

My question was if it is problematic if dmd inserted a `return` 
before any `ref` parameter a function returns.

Did the removed code which checked for returning ref parameters 
have false positives?

If not again my question: Under what circumstances would it be a 
mistake to insert `return` before the respective `ref` parameter?





More information about the Digitalmars-d-learn mailing list