(j3.2006) Did we intend to prohibit this?
Thu Mar 9 20:32:02 EST 2017
Yes this was all deliberate.
The result of a function with an allocatable result variable is not itself a
variable and therefore not allocatable. It's just a value.
>description of move_alloc doesn't say FROM has to be a variable, but its
>intent is INOUT.
So yes the description of move_alloc DOES effectively say that it has to be
"The INTENT (INOUT) attribute for a nonpointer dummy argument specifies
that any actual argument that corresponds to the dummy argument shall be
> The OUT part of its INOUT has nothing to do with its
>value, only its allocation status (which becomes unallocated).
Only variables have allocation status. Only variables and components can
have the ALLOCATABLE attribute. (We used to say this explicitly, but we
seem to have dropped it for some reason; but anyway, there are no specified
semantics for anything other than a variable or component to be
>We don't have any trouble saying that an allocatable function result is
>deallocated after it's used.
It's the function result *variable* that gets deallocated (after the value
> Why do we have a problem with FROM?
>Did we intend to prohibit this?
>If I do
Whether processors do or do not do some clever optimisations is not the
purview of the standard.
Perhaps it would be better to be using an allocatable dummy argument if you
want to do your own optimisations.
.............Malcolm Cohen, NAG Oxford/Tokyo.
More information about the J3