Am 10.08.22 um 13:12 schrieb Thomas Koenig:
> FortranFan <
pare...@gmail.com> schrieb:
>> On Tuesday, August 9, 2022 at 10:53:00 AM UTC-4, Thomas Koenig wrote:
>>
..
>>
>> At first glance at the code (I did not copy and paste it to try
>> it with Intel Fortran), the following in the standard appears
>> applicable, "A nonpointer, nonallocatable object that is not a
>> dummy argument or function result is finalized immediately before it
>> would become undefined due to execution of a RETURN or END statement
>> (19.6.6, item (3))."
>
> I saw that, but it did not seem to apply due to the definition of a
> function result in
5.4.3.1: "A data entity that is the result of the
> execution of a function reference is called the function result."
>
I would say that 7.5.6.3.7 applies (a function result is an intent(out)
dummy argument of a procedure), 7.5.6.3.3 explicitly excludes function
results, or?:
"When a procedure is invoked, a nonpointer, nonallocatable, INTENT (OUT)
dummy argument of that procedure is finalized before it becomes undefined."
and then 19.6.6.15 c) applies:
"When a procedure is invoked an actual argument corresponding to a dummy
argument with INTENT (OUT) becomes undefined except for" [....any
nonpointer default-initialized subcomponents of the argument (doesn't
apply)],
An actual argument R1524 is one
entity (R1524) that appears in a procedure reference,
with
procedure reference
"appearance of a procedure designator, operator symbol, or assignment
symbol in a context requiring execution of the procedure at that point
during execution; or occurrence of defined input/output (13.7.6) or
derived-type finalization (7.5.6.2)"
> It is also strange because the object that is returned does
> not become undefined due to RETURN or END. Rather it becomes
> inaccessible (and could be defined to become undefined) once the
> assignment is complete.
>
> I am more than happy with nagfor's and xlf's behavior, because it
> certainly is the right thing to do, but I have not yet to find
> a justification for it in the standard.
>
> Also, I do not see a change in 22-007r1.
>
> (And taken note 1 to 7.5.6.3 into account, it would make no sense
> _not_ to finalize).