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